crossbeam-rs / crossbeam

Tools for concurrent programming in Rust
Apache License 2.0
7.17k stars 454 forks source link

Channel traits #274

Open tekjar opened 5 years ago

tekjar commented 5 years ago

Hi. Is it possible to expose any crossbeam channel traits so that I can use select! with other streaming data? Like if I could implement some traits on TcpStream and do a select on this socket and other channel rx

ghost commented 5 years ago

We could do something like that in theory, but then we're essentially reinventing mio/futures in the form of channels.

I wonder - wouldn't it be easier for you to use Tokio for reading from TcpStream than spawning threads and sending messages through channels? The only reason I see for not using Tokio in this situation is that it's still painful to use due to the lack of async/await. Or is there something else I'm missing?

ghost commented 5 years ago

cc @matklad Might be interesting.

matklad commented 5 years ago

Yeah, I think I could use an API like Sink and Stream traits from futures 0.3 with crossbeam channel. Basically, wrap both Sender and Receiver into traits which provide monadic interface, but still work with select!.

On the other hand, there's a single place in rust-analyzer code base where I really have a need for this, all other current usages of crossbeam-channel definitely benefit from the fact that channels are simple concrete types.

I also probably could just use the futures streams in the blocking mode, if futures were more stable :) It would be great if, when futures are stable, there's only one channel implementation which works both in sync and async worlds.

I could also imagine a bridge between crossbeam-channel and futures, so that, if one wants to have a monadic operations, one writes receiver.into_stream().

maxgorovenko commented 2 years ago

@matklad could you share little example of wrapping Receiver into traits which provide monadic interface, but still work with select!? I'd be very grateful.

morrisonlevi commented 2 years ago

I would like trigger a task whenever a certain amount of CPU time has elapsed, not wall time like a Duration. As far as I can tell, there's no way to do this without having these traits, right?