Hello again! Sorry for not answering all of your questions.
libuv is a single-threaded library, and everything, except, uv_work_cb's are executed in the same thread, where uv_run() "runs". There are at least two ways, how you could make libuv-based app use all available CPUs: load-balancing incoming sockets via IPC pipes to child process or worker threads (each with it's own libuv loop) or listening on the same fd. Node.js was using latter approach up until v0.11 that will become v0.12 soon. Cheers, Fedor. On Wed, Jan 22, 2014 at 3:02 PM, <[email protected]> wrote: > Thank you for the answers! I used libevent previously, so I was > confused about the different nature of libuv. > > I took a look at the NodeJS source code, and how it uses libuv, and one > question remains. > > Is the default event loop/main thread used for everything? Assuming a > request comes in, this thread alone will: get notified about the event, > read the data, run the callback, and then write back a response? All of > this on a single thread, for any number of requests? > > I read parts of the NodeJS code, but I couldn't find anything that > points to any thread parallelism (except from debugging). It seems that > even uv_queue_work is not even being called much. > > > If this question is too specific, let me know and I'll ask it in the > NodeJS mailing list. > > > Allan > > On Friday, January 17, 2014 4:35:40 PM UTC-2, Fedor Indutny wrote: >> >> Hello! >> >> You should not call anything except `uv_async_send()` from another >> thread. Many functions are inserting stuff into loop's linked lists >> and the list itself is not thread-safe (not even talking about many >> other internals). >> >> `uv_async_send()` indeed writes to one end of the pipe, and libuv is >> listening on the other end of the pipe, and interrupts loop and >> invokes callback when receives data. >> >> As a way to return data back from uv_work_cb - you could set and >> change req.data safely inside worker thread, it'll be available in >> uv_work_done_cb. >> >> Cheers, >> Fedor. >> >> On Fri, Jan 17, 2014 at 6:19 PM, <[email protected]> wrote: >> > Hi, >> > >> > I've been curious about how libuv works internally regarding thread >> > communication. >> > >> > This is what I understand: >> > There's a single thread running uv_run. If I spawn some work to be done >> > in another thread I'm supposed to use uv_queue_work. The way to send >> > the results of this work back to the main thread is through >> > uv_async_send (which is the only thread-safe function in libuv). >> > >> > This is what I want to do: >> > Start listening on a TCP socket, accept incoming connections in the >> > default loop, and wait for data to be available for reading (using >> > uv_read_start). When it's available for reading, I'd put the work >> > (socket reading) in the queue (with uv_queue_work), and the callback >> > for this would run in another thread, reading the data and performing >> > some work based on it, which may involve writing data back to this or >> > any other socket. >> > >> > So, my questions related to this are: >> > - Is this possible to do? If I call uv_read_start and uv_write in >> > another thread, can this cause trouble, because they should have been >> > called in the default loop? >> > >> > - If uv_read_start and uv_write should be called in the default loop, >> > then the main thread will be responsible for reading and writing all >> > data, right? Wouldn't this impact performance? How does NodeJS deal >> > with this? >> > >> > - How does uv_async_send work? From a quick glance at the source code, >> > I suspect it sends data in a file descriptor, which will be read in the >> > default loop. Is this what is happening? >> > >> > >> > Allan >> > >> > -- >> > 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 http://groups.google.com/group/libuv. >> > For more options, visit https://groups.google.com/groups/opt_out. -- 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 http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/groups/opt_out.
