Move queues into a new crate

[ghost]

So far, I've been hesitating splitting Crossbeam into multiple crates any further, at least until there comes a need for it. The time has now come since we'd like to use SegQueue in Tokio without pulling in the whole crossbeam crate as a dependency. Rayon needs SegQueue for FIFO scopes as well.

So the question is where should we move SegQueue, MsQueue, and soon to be merged ArrayQueue? I suggest taking the simplest possible option - just put them into a new crossbeam-queue crate. In the future we'd probably like to add more types of queues and parts of circbuf (#277) that make sense.

How does everyone feel about this?

[BurntSushi]

The time has now come since we'd like to use SegQueue in Tokio without pulling in the whole crossbeam crate as a dependency.

Could you say more about the motivation for this?

[ghost]

Could you say more about the motivation for this?

Sure. There are places where we really only need SegQueue and the only way to get it is to add crossbeam as a dependency. However, that transitively also adds crossbeam-channel, crossbeam-deque (and soon also crossbeam-epoch), which are pulled in despite not being needed at all. It'd be nice to pull in only what you need.

The crossbeam crate is a batteries-included library with tools for concurrency. It's handy when you're writing an application, but libraries prefer to have as few dependencies as possible, so we'd like to give them a choice to pick the parts they need.

Tokio is for the same reason split into tokio, tokio-executor, tokio-threadpool, tokio-fs, and so on. Applications are expected to use the main tokio crate, but libraries should only pick the parts they actually need.

[BurntSushi]

Ah, thanks for explaining. I guess it would be nice to see that philosophy applied elsewhere. For example, crossbeam-channel is definitely something that other libraries might want to use, but today it brings in 32 (I think?) crates. I'm guilty of this myself as well. I don't quite know how to combat it unfortunately.

Anyway, I think your proposal makes sense!

[ghost]

I have plans to reduce dependencies of crossbeam-channel as well. Most of those probably come from parking_lot, which will hopefully soon get into the standard library.

[ghost]

@jeehoonkang @Vtec234 I'm especially interested in your thoughts on this. :)