https://docs.rs/crossbeam-channel/0.1.2/crossbeam_channel/ probably has a better MPMC implementation than my hacky one. Look into using that.

Could with_threads(0) mean number of CPUs in the system? That's actually most typical usage.

Any chance of getting ordered output? Only then it's a plug-and-play solution for everyone.

Pipeliner was created before Rust's async/.await functionality became available in stable. It uses OS threads for both CPU-bound and I/O-bound computation. But async code is much more efficient for I/O-bound work, since you can efficiently wait for I/O without needing a whole thread.

I'd like to update Pipeliner to support async I/O. Some thoughts:

• allow mixing async/sync code. This would work well for putting I/O-bound code in async executors, and CPU-bound code on threads.
• Is there a way to make it pluggable so it works for tokio and async-std, or do I need to do that manually w/ feature flags?

If you'd like this feature, please leave a comment or👍.

Add an option to require ordered output.

I was wondering if you could upgrade the crossbeam-channel version.

Why does PipelineBuilder::map require a callable that has a lifetime of static? Is there a problem with passing through the lifetime of whatever callable is provided? (i.e. the callable has to live at least as long as the iterator does so that there's no attempt to call a deallocated object) I ask because I was attempting to use this in a context where the callable was a closure, which I believe is sound because I reduce the iterator before the caller to map exits, so there is no possibility of calling a deallocated function.