It is nice to see that you already have done something in a similar
About the uv_async_send, here is what I was thinking about:
Instead of using this:
async.data = my_data_ptr;
We would include the data pointer in the uv_async_send call:
Then the libuv would push it into a queue and fire the thread signal.
In the receiver side, as the calls coalesce, each time a call is fired it
must retrieve all the pointers from the queue until it's empty and call the
callback function for each data. Here is a pseudo-code:
while(data = dequeue(async->queue)):
But I notice a possible problem. We would need to use a mutex to handle the
queue, and uv_async_send is also used for simply returning a pointer or a
value to the main loop. There's no need to mutexes in these simple cases.
So maybe we could use another function name for it, as you propose the
Here comes the question: Why not use sockets or pipes in these cases? The
reason is because they copy the entire data and it would be better to have
a copy-free alternative.
Poul, your idea is in this direction. Congrats! You send just the pointer
over the pipe. And in synchronous calls it doesn't even use calloc, but
just the stack. Really nice! Thank you for sharing it.
It also remembers me of the uv_work_t.
So, lets review:
The libuv would then have:
-uv_work_t for "sending work" to the thread poll;
-uv_async_send to return value to the main loop or to send notifications;
-uv_callback (or another name) for the worker thread to call a function in
the main loop.
And the uv_callback could be used so in async mode as in sync mode.
Is it right? Will it solve our needs?
It would be good to have other ideas in this discussion.
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.