-
Notifications
You must be signed in to change notification settings - Fork 229
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use crossbeam-channel instead of stdlib #160
Comments
v4 is in maintenance only, v5 (aiming for end of this year) uses a significantly different architecture based on Tokio and Futures. Internally, v5 uses multiqueue channels for some plumbing which I believe use crossbeam. Externally, in v5 you'll just subscribe to a |
Excellent, that should be even better! Thanks! |
If v5 is still some time away, are there any chances for this to be implemented in v4? |
Hmm, I'll take an implementation if someone wants to. The remaining question I think would be whether to be generic over only the channel exposed through the public API (which would be simpler), or to be generic over every channel use inside this library (which would likely help the performance characteristic further than just the last hop, varying on internals). |
Shifting this to be purely crossbeam-channel as originally alternately proposed. If there's interest in making it generic I'm happy to take an implementation later. |
Only a straight find-replace was done. There are many places where std channels were placed in mutexes and arcs; this is not necessary anymore but needs more careful refactoring. See #160
Only a straight find-replace was done. There are many places where std channels were placed in mutexes and arcs; this is not necessary anymore but needs more careful refactoring. See #160
Only a straight find-replace was done. There are many places where std channels were placed in mutexes and arcs; this is not necessary anymore but needs more careful refactoring. See #160
Only a straight find-replace was done. There are many places where std channels were placed in mutexes and arcs; this is not necessary anymore but needs more careful refactoring. See #160
Done in 0eb4f2e and parents |
FWIW, I slowly coming to conclusion that accepting an |
Sorry, stupid and confused person here, if I'm using 4.x branch, what is the best way to start using Crossbeam channels? Is such even possible? |
Hi! My understanding is that currently
notify
hard-codes the usage ofstd::mpsc
, and this is a bit unfortunate: there are many channel implementations in Rust (crossbeam-channel
most notably), and the std version is not really great: it lacksselect
, which severally restricts its applicability.It would be cool if
notify
had atrait EventSink { fn send(&mut self, Event); }
and used that instead of any particular channel implementation.Though, for practical purposes, perhaps just betting on
crossbeam-channel
would be even better?The text was updated successfully, but these errors were encountered: