ewebsock icon indicating copy to clipboard operation
ewebsock copied to clipboard

No-blocking operations for web based clients

Open S0c5 opened this issue 1 year ago • 9 comments

S0c5 avatar Mar 06 '24 01:03 S0c5

What are you trying to accomplish? The current design of ewebsock is already non-blocking

emilk avatar Mar 08 '24 12:03 emilk

Hello @emilk, thanks for your response, we used ewebsokets to implemented this https://github.com/virto-network/virto-sdk/blob/8e5fadbb4e415e9514b5365401f3598d8264668e/sube/src/ws.rs while I saw we can use the wake up function, there are situations where the context that the wake up needs is not longer accesible by it. In our case we need to "wait" until new messages are coming, but as you were using "try_receiv" it requires to have a loop in a new thread that constantly are asking if there are new messages available, thats why I migrated it to use Future Streams to "wait" until a new message are ready and avoid use a blocking loop and use the same thread in web or native contexts.

// before
 // waits to wake up function to be called
 while let Ok(Some(event)) = receiver.try_receive() {
 
 }
// now you can use this  without blocking the current thread
  while let Some(event) = receiver.next().await { {
        // custom logic here
    }

S0c5 avatar Mar 10 '24 23:03 S0c5

Hey @emilk , did you have the chance to review it?

S0c5 avatar Mar 19 '24 23:03 S0c5

@emilk any thoughts on top of this? or do you recommend to fork a new brand library with this specific changes?

S0c5 avatar May 02 '24 17:05 S0c5

I'm sorry, I don't have a lot of time on my hands.

I don't want to add a bunch of async to ewebsock if it can be avoided. I also don't want the API for web and native to diverge.

If you want to be able to write .await instead of using the callback-based API, then please see if that is something you can build on top of the existing ewebsocket API. If not, make it opt-in.

emilk avatar May 21 '24 16:05 emilk