You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
crossbeam is a pretty big dependency for a small crate so would be nice to be able to use this crate without bringing in all of crossbeam. Ran esp. into this with #16 where the old crossbeam version had a flagged security vulnerability in the old memoffset crate.
As ThreadMode::Sequential is default anyway, having an optional feature flag that adds the crossbeam dependency and exposes the ThreadMode::Parallel would be great and then. And not having this feature flag in the default feature listing, so crates have to opt in to the parallel crossbeam code instead if they want to use it.
Would such a change be ok? Would be a breaking change was ThreadMode::Parallel would only be exposed if the parallel feature flag is used. But would likely be ok as this crate is not at 1.0 stable yet
The text was updated successfully, but these errors were encountered:
Thanks for creating this issue. Pull request #19 changes the dependency from crossbeam to crossbeam-utils which pulls in less dependencies. Would this suffice for your use case?
This definitely does reduce the amount of dependencies, which is great.
I'm a bit hesitant to smaller libraries having their own thread spawning or parallelism in general, as that is pretty heavy duty operations, so do think a feature flag would be the nicest. But this is not a major issue for us after the PR has been merged in so np to close this
crossbeam
is a pretty big dependency for a small crate so would be nice to be able to use this crate without bringing in all of crossbeam. Ran esp. into this with #16 where the old crossbeam version had a flagged security vulnerability in the oldmemoffset
crate.As
ThreadMode::Sequential
is default anyway, having an optional feature flag that adds the crossbeam dependency and exposes theThreadMode::Parallel
would be great and then. And not having this feature flag in the default feature listing, so crates have to opt in to the parallel crossbeam code instead if they want to use it.Would such a change be ok? Would be a breaking change was
ThreadMode::Parallel
would only be exposed if the parallel feature flag is used. But would likely be ok as this crate is not at 1.0 stable yetThe text was updated successfully, but these errors were encountered: