Thanks for all the information! Just to clarify a couple of things about the threading:
1. The device (an embedded device) has a single core anyway. The threads are only there to manage blocking code that can't be (or hasn't been) broken up into events. 2. I do the message handling in the main loop because a lot of it relates to a GUI which has to be serviced via a single thread or locked with mutexes. The GUI event loop is already managed by a libuv timer. > if you want libuv to continue processing other things while you are processing a message invoking the functions I am not so concerned about processing things in actual parallel, it's more that if libuv has some other things ready to go (eg. requests to handle, buffers to fill) I was wondering if I could be "polite" and interleave my handlers with libuv's, still in one thread. Kind of like yielding in other async frameworks (eg. Python's asyncio). > what if items come in faster than the main thread can dispatch them? It's an embedded system with a known set of things-to-do, so I can make a decent estimate of the maximum number of events that can accumulate (and a caller will know when pushing to the message queue fails, and can... theoretically... handle that). After reading the API docs again, I think that a timer with delay = 0 and repeat = 0 is essentially what I want to do - one for each message. Or perhaps a uv_async_t and then an immediate async_send? The docs say that the async handler can be invoked at any time after that call, including before the calling function returns, but I assume that only applies when you're calling it from a thread different to the one the main loop is running in? Thanks, Jason -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/libuv/bad354f3-ca15-409e-9798-644fe760d0a8n%40googlegroups.com.
