[feature request] re-expose try_recv() about chan HOT 8 CLOSED

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.