Skip to content

No-blocking operations for web based clients #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

S0c5
Copy link

@S0c5 S0c5 commented Mar 6, 2024

No description provided.

@S0c5 S0c5 force-pushed the enhacement/aviod-blocking-operations-with-mpsc-futures branch from dd089ea to 2d0fbad Compare March 6, 2024 01:55
@emilk
Copy link
Member

emilk commented Mar 8, 2024

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

@S0c5
Copy link
Author

S0c5 commented Mar 10, 2024

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
Copy link
Author

S0c5 commented Mar 19, 2024

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

@S0c5
Copy link
Author

S0c5 commented May 2, 2024

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

@emilk
Copy link
Member

emilk commented May 21, 2024

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 emilk marked this pull request as draft May 21, 2024 16:01
@ChocolateLoverRaj
Copy link

I would be interested in an async API for both web and native.

@c-git
Copy link
Collaborator

c-git commented May 14, 2025

I'd actually be interested in more opinions on this. I do currently use a async API on top of ewebsock in my project. I also needed it to support timeouts. I'm curious about what other people would need.

To be clear I do want to keep any async we add separate so that users can opt in if the choose.

@ChocolateLoverRaj
Copy link

@c-git @S0c5 there is another WebSocket library: https://github.com/nash-io/nash-ws. It works with async on both web and native. I'm using it.

@c-git
Copy link
Collaborator

c-git commented May 17, 2025

@c-git @S0c5 there is another WebSocket library: https://github.com/nash-io/nash-ws. It works with async on both web and native. I'm using it.

Thank you for the reference but the non-async version of this library is important because I don't always make calls to the functions from an async context and need to not block as I'm using it in an update loop of egui.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants