[libuv] Re: Suggestion for v2: uv_async_send
Implementation of uv_callback here: https://github.com/litesync/uv_callback -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
[libuv] Re: Suggestion for v2: uv_async_send
This last idea also solves the problem of uv_async_send not being thread safe. If we use the LIBUV_ASYNC_USE_QUEUE option on it, then it can be called even by many worker threads at the same time. This is another use case I did not put in the last e-mail. -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
[libuv] Re: Suggestion for v2: uv_async_send
I have another idea: What about the coalescing calls in the uv_async_send to be optional? So we can choose if the calls will coalesce or not. This could be set in uv_async_init. Because in some cases it is useful, as when the worker thread wants just to notify progress to the main thread. libuv behavior: When coalescing is ON: -libuv will NOT use a mutex and the value passed in the uv_async_send is put in the async_t->data When coalescing is OFF: -libuv will put the data pointer into a queue inside the async_t, using a mutex Let's review the use cases: ASYNCHRONOUS CALL + COALESCING ENABLED: -the worker thread will just send the return value to the main thread. The uv_async_send will be called just once. -the worker thread will send update notifications to the main thread as a single integer value, like a percent status. -the worker thread will send update notifications to the main thread as a pointer to a struct or string that is statically allocated and the content will not be modified. ASYNCHRONOUS CALL + COALESCING DISABLED: -the worker thread will send update notifications to the main thread as a pointer to a struct or string that is dynamically allocated (and must be free'd by the main thread). SYNCHRONOUS CALL: -the worker thread will send update notifications to the main thread as a pointer to a struct or string that is statically allocated but the content can be modified. It can be configured like this: uv_async_init(loop, , my_callback, LIBUV_COALESCE); uv_async_init(loop, , my_callback, LIBUV_NO_COALESCE); uv_async_init(loop, , my_callback, LIBUV_SYNCHRONOUS); Or maybe setting it in the async struct. In this case we can use a default value and for backwards compatibility it can be with the coalescing of calls enabled. If we need to change the option, the usage would be something like this: async.options = LIBUV_NO_COALESCE; If for some reason the call coalescing cannot be disabled, we just rename the options like: LIBUV_COALESCE -> LIBUV_ASYNC_NO_QUEUE or ... LIBUV_NO_COALESCE -> LIBUV_ASYNC_USE_QUEUE or ... And then when the callback is fired the libuv retrieves all the items from the queue and calls the callback function for each returned value. WDYT? -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
[libuv] Re: Suggestion for v2: uv_async_send
Hi Guys! It is nice to see that you already have done something in a similar direction. About the uv_async_send, here is what I was thinking about: Instead of using this: async.data = my_data_ptr; uv_async_send(); We would include the data pointer in the uv_async_send call: uv_async_send(, my_data_ptr); 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)): fire_callback(async->function, data) 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 uv_callback. 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; and -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 "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to libuv+unsubscr...@googlegroups.com. To post to this group, send email to libuv@googlegroups.com. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
