-
Notifications
You must be signed in to change notification settings - Fork 1.8k
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
The uWS::Loop::get()->defer method will block the reception of subsequent messages. How should this be handled? #1844
Comments
Make the message handler acquire a mutex, add the message to a queue, and release the mutex. That will be a fast-running handler that will block the uWebSockets run method for a very short time. Make another thread acquire the same mutex, pop off the message to a local variable, and release the mutex. After the mutex release, make that thread parse the message. If it is a play message, make it run your code that computes the data that needs to be sent to the client. Then make it call
Notice that that code does not have a call to the time-consuming play function. The above code snippet will run fast meaning it blocks the uWebSockets run method for a very short time. |
Is it like this? The program runs fine, but the browser doesn't receive any data.
|
Add a If I am right, then I think you have the same problem as in #1118. I.e. your When your message handler creates a new thread, pass that thread a loop in the lambda capture section. Then pass that loop onto play and again to the lambda in play so that lambda can call defer on that loop. BTW, your code creates a new thread every time you receive a message. If you receive messages often that would create a lot of overhead. Since you said that play is long-running, that means it will take a long time before the thread ends. If you get another message before the previous thread has ended then now you have two new threads running. If you receive messages often you could have a very large number of threads running at the same time which might use up too much CPU time. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
play is a time-consuming task, and calling this method blocks the reception of subsequent messages. How should this be handled?
The text was updated successfully, but these errors were encountered: