Question: Is Flume production ready?

[ev94]

Hi,

Thx for the great work.
Is Flume production ready? Are there any known limitations?

Cheers,
Emmanuel

[zesterer]

The last bug that I'm aware of (an issue that only affected Selector) was fixed in #69, almost 2 weeks ago.

Flume is used by a variety of relatively large crates at this point and has a very extensive test suite (most of the tests are taken from crossbeam-channel's tests).

I'm not aware of any limitations. I do have an experimental from-scratch refactor in the works that shakes up the architecture in the name of efficiency (and permits no_std support, funnily enough), but that's unlikely to be ready for a few months, and I'm still maintaining the current implementation.

I'd say: give Flume a try! It's not using any unsafe so I'd argue that it represents less of an attack vector than other crates that do use a lot of unsafe to achieve the same thing.

[ev94]

Thanks. That's a great news. We will be pleased to do so.

[sjmackenzie]

Flume is looking great. I need to sink my networking protocol to no_std. I'm curious if the no_std compatible anchitecture is viable or not.

[zesterer]

Flume is looking great. I need to sink my networking protocol to no_std. I'm curious if the no_std compatible anchitecture is viable or not.

I have a much more modular no_std version of Flume in development that's based on an async core. Although obviously waiting on a channel requires std, it will eventually be possible to disable these features and use Flume on no_std provided you either have an async runtime available, or you only use the try_send/try_recv methods. I don't currently have a timeline for this because I'm in the middle of some fairly big refactors of some of my other crates.