Deferred action on a closed socket #1822
-
Hi! I have a scenario with The issue occurs only under a fair load (100+ connections).
In such a situation, I would like a way to remove actions for the I have some ideas: I could create my own queue (instead of Loop's deferQueues), so I can remove actions for I know I could use a timer via Could you suggest some direction? |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 3 replies
-
Could possibly add ability to remove queued functions if the receiver holds
the queue mutex for the full duration of the execution.
But you can also just capture a shared_ptr to determine if the function is
still valid.
But yes, this is probably a good idea to add. If defer returns an integer
or something.
Need to think about it
Den tis 10 dec. 2024 20:34arroyo-pl ***@***.***> skrev:
… Hi!
I have a scenario with ws as a pointer to a WebSocket object and two
threads: a worker thread and a main thread (running the uWS event loop).
The issue occurs only under a fair load (100+ connections).
- *Worker thread*: Adds a deferred operation to *ws* using loop->defer([ws]
{ ws->write("test"); });.
- Meanwhile, in the *main thread* (event loop):
- WebSocket is disconnected. I receive the close event but have no
control over the deferred operation queue.
- The loop attempts to perform the deferred operation on the
disconnected ws, leading to a an AddressSanitizer error.
In such a situation, I would like a way to remove actions for the ws
object, but how can I achieve that?
I have some ideas: I could create my own queue (instead of Loop's
deferQueues), so I can remove actions for ws on close event, but I’m not
sure how to execute it efficiently.
I tried hooking into Loop::addPreHandler / addPostHandler, but those are
invoked at too long intervals. I also attempted to "wake up" the loop after
adding something to the queue by using us_wakeup_loop to force the
pre/postHandler execution, but it didn’t work.
I know I could use a timer via us_create_timer, but in this case, I need
to set a fixed interval, e.g., 50ms. However, this would make the
application less responsive. Setting an interval like 1ms would be
excessive on the other hand.
Could you suggest some direction?
Thanks!
—
Reply to this email directly, view it on GitHub
<#1822>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/A2NMOMIIBOEHII5VP56LGXL2E462RAVCNFSM6AAAAABTL4UR3KVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZXGY2TENJWGQ>
.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
Thanks! |
Beta Was this translation helpful? Give feedback.
Here's chatgpt reformulating it
You're describing a common design pattern in asynchronous programming with Boost.Asio, where the lifetime of operations and objects is managed using smart pointers. This approach works well to emulate cancellation by simply letting the owning shared pointer expire, which invalidates any weak pointers in flight. Here’s a breakdown of how and why this works:
The Design Rationale
Async Operations are Non-Cancellable: Boost.Asio doesn’t inherently support reliable cancellation of asynchronous operations. If you attempt to cancel an operation, it might still complete in some cases. The library’s design avoids guarantees for cancellation reliability to keep opera…