Closed Levyks closed 6 months ago
nevermind, I was reading through #22 and found the cancel_safety
example and that approach of using select!
with a separate channel
appears to be exactly what I needed.
but maybe that example could be renamed to something different to make it easier to find when searching for something like my issue? Or maybe add a reference to it in the README.md
, since processing messages in a async way is such a common use-case for this kind of crate
Thank you for the information. That example was really to show and allow users to test that the APIs are cancellation safe which is kinda implied if you want to use the select!
macro. That kind of use pattern, to me, is more like something enabled by the tokio or async rust ecosystem, and this is why I didn't make a separate example.
@Levyks #229 is published in version 0.9.6
thanks for the quick merging/publishing
Is there some way to process messages in another tokio thread, so that long running tasks don't block my consumer from processing more messages?
My goal is to have something like the example below (doesn't work):
But since
Receiver
does not implementCopy
/Clone
, I cannot get something like this to workI've seen some crates deal with a similar issue in websockets by splitting the incoming/outgoing channels.
Would this approach be possible here? I've seen you mention in #125, that the
Receiver
struct itself can never implementCopy
/Clone
astokio::sync::mpsc::Receiver
does not as well, but thetokio::sync::mpsc::Sender
used inoutgoing
does, but for that to work thelink
property would need to beCopy
/Clone
, is that possible?EDIT: Or maybe there is already a workaround that lets me do that without implementing anything new at the crate level?