crossbeam icon indicating copy to clipboard operation
crossbeam copied to clipboard

Channel traits

Open tekjar opened this issue 6 years ago • 5 comments

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

tekjar avatar Dec 19 '18 13:12 tekjar

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 avatar Jan 01 '19 15:01 ghost

cc @matklad Might be interesting.

ghost avatar Feb 13 '19 13:02 ghost

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().

matklad avatar Feb 13 '19 15:02 matklad

@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.

maxgorovenko avatar Oct 24 '21 17:10 maxgorovenko

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?

morrisonlevi avatar Jun 01 '22 14:06 morrisonlevi