Comments (8)
I think my primary question is: why do you want to do a non-blocking recv
in the first place? (I don't doubt that their are use cases, but they feel kind of rare in the context of blocking channels.)
Otherwise, I think I'm OK exposing this method since I do feel like you make a reasonably compelling argument. I wish chan_select!
were more ergonomic, but I don't think that's going to happen until we get better macros/plugins on Rust stable. (Which I don't see happening any time soon.)
especially since it seems like upstream is never going to stabilize Select in std::sync::mpsc, so chan is going to be increasingly popular for people who want CSP semantics.
Yeah, Select
in std::sync::mpsc
is not so great. The fact that it's unstable isn't its only problem; it also can't synchronize across channel sends and I don't believe supports default
. The tracking issue is here (where I've just suggested that we remove it entirely): rust-lang/rust#27800
I wonder if crossbeam
could be made to add a "select" with its sync::MsQueue
type. If crossbeam
got that, then I think that would almost make this crate obsolete. (MsQueue
is an asynchronous channel while chan
exposes both asynchronous and synchronous channels.)
from chan.
@BurntSushi I think trying to read all pending messages on a channel without going back into select!
is a pretty common pattern. In this case, the application is (roughly) reading all of the pending messages on one channel, slightly modifying them, then adding them as a batch to another channel for some other thread to work on en masse.
from chan.
That actually sounds a little weird to me. I don't think I've ever had the
occasion to do that. (If I need batches then I would probably do it
explicitly with a vec or something.)
I don't want to belabor this too much. I am okay with exposing this, but i
would like to understand the use cases better.
On Nov 3, 2016 11:49 PM, "James Brown" [email protected] wrote:
@BurntSushi https://github.com/BurntSushi I think trying to read all
pending messages on a channel without going back into select! is a pretty
common pattern. In this case, the application is (roughly) reading all of
the pending messages on one channel, slightly modifying them, then adding
them as a batch to another channel for some other thread to work on en
masse.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAb34pI87UQElwClXb2jBokvMzY3m03pks5q6qs-gaJpZM4Kmyqn
.
from chan.
Um, one of the places I use it (which I haven't actually tried to port to chan
yet, but which I think is clearer) is a wrapper library for talking to Kafka. The C library I'm wrapping there (librdkafka
) takes batches of messages for efficiency; I want to expose an asynchronous channel interface. So I use try_recv()
to grab all of the single messages posted by various other producer threads, then pass that downstream as a single batch.
from chan.
Incidentally, the code could be simplified a bit if I had a select with timeout (like select(2)/poll(2)/et all). I guess I could emulate that with an extra thread which emits a tick onto a channel periodically, but shrug. There's always another way to write something.
James Brown,
currently mobile
On Nov 3, 2016, at 20:52, Andrew Gallant [email protected] wrote:
That actually sounds a little weird to me. I don't think I've ever had the
occasion to do that. (If I need batches then I would probably do it
explicitly with a vec or something.)I don't want to belabor this too much. I am okay with exposing this, but i
would like to understand the use cases better.On Nov 3, 2016 11:49 PM, "James Brown" [email protected] wrote:
@BurntSushi https://github.com/BurntSushi I think trying to read all
pending messages on a channel without going back into select! is a pretty
common pattern. In this case, the application is (roughly) reading all of
the pending messages on one channel, slightly modifying them, then adding
them as a batch to another channel for some other thread to work on en
masse.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAb34pI87UQElwClXb2jBokvMzY3m03pks5q6qs-gaJpZM4Kmyqn
.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
from chan.
OK, so this method already exists, but it's not exposed. Here is its signature:
fn try_recv(&self) -> Result<Option<T>, ()>;
The return type seems a little strange to me. Ideally, it would just return an Option<T>
, but recv
already returns an Option<T>
. Specifically, in the case of recv
, None
is returned if the channel is closed.
An Option
nested in a Result
seems a little unfortunate. Should we instead return a custom enum? e.g.,
enum Try<T> {
Some(T),
WouldBlock,
Closed,
}
That seems more explicit to me.
from chan.
That seems way better!
James Brown,
currently mobile
On Nov 4, 2016, at 06:30, Andrew Gallant [email protected] wrote:
OK, so this method already exists, but it's not exposed. Here is its signature:
fn try_recv(&self) -> Result<Option, ()>;
The return type seems a little strange to me. Ideally, it would just return an Option, but recv already returns an Option. Specifically, in the case of recv, None is returned if the channel is closed.An Option nested in a Result seems a little unfortunate. Should we instead return a custom enum? e.g.,
enum Try {
Some(T),
WouldBlock,
Closed,
}
That seems more explicit to me.—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
from chan.
This crate is now deprecated. See: https://users.rust-lang.org/t/ann-chan-is-deprecated-use-crossbeam-channel-instead/19251
from chan.
Related Issues (19)
- remove hyper dev dependency HOT 4
- Possible memory leak in `tick` HOT 2
- How to chan_select over multiple chans that will terminate? HOT 1
- Using chan_select! requires values to be 'static HOT 3
- Add timeout-able methods HOT 1
- doesn't seem to work with `fork()` HOT 2
- Select integration with std lib mpsc api HOT 4
- Allow chan_select to generate no-op None variants HOT 2
- Sender::send(t) -> Result<(), SendError> HOT 16
- Deadlock with select-send and select-recv HOT 2
- crossbeam-channel – EOL chan HOT 6
- Broadcast to all consumers HOT 4
- Return value from `chan_select!` expression HOT 2
- chan::async() conflicts with Rust 2018 Edition HOT 6
- I think it's butter to return a Result for invalid add HOT 5
- Relicense under dual MIT/Apache-2.0 HOT 8
- Async channel is blocking program HOT 9
- All Notifier subscriptions made in select.rs appear to be leaked HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from chan.