On 07/26/2016 04:20 PM, Pierre-Yves Ritschard wrote: > Hi, > > I'm trying to work out how to correctly implement the following: > > - I have a thread that handles all network I/O in a program > - I have a number of threads that each watch over a specific resource > > When a request comes in from the network, I enqueue to the appropriate > resource's input queue and signal it through a > uv_cond_t condition variable. > > The thread pops the request, handles it and enqueues the response in a > global response list. > > What I want to ensure is that the response list gets popped at > sufficient interval and that I/O happens on the I/O thread. > To do that, it seems that registering uv_check_t and/or uv_idle_t > handlers would handle both the after polling for I/O and > when stuck polling for I/O. > > When registering both, the CPU goes through the roof which seems to > indicate that it gets called way too often. > Should I go another away about doing this? >
The libuv event loop will block zero milliseconds when there is any idle handle active, hence the increased CPU usage you're seeing. Once way to solve this is to have a uv_async_t handle which you signal from the outside threads using uv_async_send (this function is thread safe) and in its callback (which is called in the loop thread) process the response queue. Cheers, -- Saúl Ibarra Corretgé bettercallsaghul.com -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
