I wonder that you can't pass uv_tcp_t pointer to any other threads, cause it's not safe. As describe by others, it's like an active object if i am right? Handle an income connect and receive some message, pass these messages to worker thread and process async-ly. when it's done post message to thread running uv_loop? If i want build a *data publish server*, maybe i should use some data structure like ring buffer to get message for each connection and *call uv_write recursivelly*？
On Wednesday, January 22, 2014 7:18:06 PM UTC+8, Fedor Indutny wrote: > > I mean using the same TCP server fd in multiple threads each with it's > own libuv loop. You'll still need to send the `uv_tcp_t` server handle > to other threads using IPC pipe (see `uv_pipe_open`). > > On Wed, Jan 22, 2014 at 3:14 PM, <[email protected] <javascript:>> > wrote: > > What do you mean by listening on the same fd? > > > > I have used the other approach when using libevent (one event loop > giving > > control of the fds to other event loops in other threads). > > > > On Wednesday, January 22, 2014 9:11:29 AM UTC-2, Fedor Indutny wrote: > >> > >> 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/d/optout.
