uv_async_send without coalescing

[jim-king-2000]

libuv will coalesce calls to uv_async_send(), that is, not every call to it will yield an execution of the callback. For example: if uv_async_send() is called 5 times in a row before the callback is called, the callback will only be called once. If uv_async_send() is called again after the callback was called, it will be called again.

What if we don't need coalescing?

And I saw #619 , it suggests we would use a thread-safe queue structure. But there is a queue in the message loop of libuv, why should we introduce another queue?

Why it forces coalescing? Is there a uv_async_send counterpart without coalescing?

[bnoordhuis]

Is there a uv_async_send counterpart without coalescing?

No. Libuv's design philosophy is to provide basic building blocks. If you want something like an (un)bounded channel, it's up to you to build out that abstraction.

[jim-king-2000]

I'm a little bit confused. If uv_async_send disables coalescing, would it violate the design philosophy of libuv?

What does node.js do? Does node.js create its own thread-safe queue structure?

[bnoordhuis]

What would no coalescing let you do that you can't do now? Or phrased another way: what exactly are you trying to accomplish?

[jim-king-2000]

When we use Node.js, we notice that it creates a great pattern of programming. That is the single-threaded mode. This mode simplifies the structure of the production code and avoids a lot of tricky defects which are introduced by multi-threaded programming such as race condition and deadlock.

When we get involved into a C++ project, I insist on the same pattern which Node.js introduces. So we choose libuv, a wonderful async framework. We expect to eliminate all of the synchronization objects such as mutex, event, etc. by means of integrating libuv.
But we meet a small problem. We employ uv_async_send in every callback which is invoked in child thread to notify the main thread. In the WebRTC callback, we would receive a lot of candidates (called trickle ice) and call uv_async_send consecutively. Since there is coalescing, we would miss most of the candidates sent from the remote server.

We have to use mutex again for introducing a thread-safe queue. We really want to remove all of the core objects and do Node.js ways in C++. Is it possible to provide an option to turn off coalescing?

[bnoordhuis]

Note that uv_async_send() won't let you send data; it's not a queue of any kind, it's just a "something happened" signal. Think of it as shorthand for uv_wake_up_event_loop_from_another_thread().

If you're asking for N calls = N callbacks behavior and nothing else, then I guess that could be implemented but it doesn't seem that useful because you still need to check what exactly happened and that's going to involve atomic variables or mutexes.

[jim-king-2000]

Inter-threaded communication always involves a small amount of data. In the doc, async.data is used to send the percentage of download to the main thread.

async.data = (void*) &percentage;
uv_async_send(&async);

We are doing the same thing. We send the candidate (a small amount of data) together with the notification signal. We just need all of them be received.

[bnoordhuis]

Caveat emptor: the guide was an external contribution that hasn't been vetted as thoroughly as the reference documentation. Not all of the advice it contains is good advice.

That example is flawed because uv_async_send() is not a memory barrier. Other threads can potentially see the effects of those two lines in reverse order. I'll remove it from the guide.

[jim-king-2000]

OK then, we'll keep our thread-safe queue. But I think libuv could be a queue. The node.js pattern is sustained by a queue.