Hello Ben, Thanks for your quick reply.
I understand that libuv is not thread safe and it's made by design. I'd like to know if we could benefit from the best of both world: multi cores cpus + event based loop without the slow downs and the complexity of mutexes, semaphores ... Correct me if I'm wrong but the problem of passing stream from one loop to another means implementing a thread safe mechanism, isn't it? Is there is any other way to implement it? I though that if I could mark a stream (or put in stasis but it seems harder to implement because I had to sync the latent data) then the other loop could import it + register file descriptor with a minimun lock risk or time consumed. This implementation will introduce a limitation one stream will only be able to be attached to 1 loop and it will be async. Anyway, you probably already think of it trying to implement isolates support for node. Thanks in advance for your help. Cheers, Mathieu On Sunday, July 1, 2012 7:14:56 PM UTC+2, Ben Noordhuis wrote: > > On Sun, Jul 1, 2012 at 7:32 AM, Mathieu Garaud <[email protected]> > wrote: > > Hello, > > > > I'm playing with the sample code uv_webserver released by Ryan Dahl and > I > > want to add thread support for incoming connection. > > > > To make it short I'm just trying to thread the on_connect > after uv_listen to > > make sure that all the tcp connections will be distributed over all the > > cpus available on my computer. > > > > After my naive attempt of creating a thread and new loop and try to use > > uv_accept I found those lines of code in unix/stream.c (line: 218-219): > > > > /* TODO document this */ > > assert(server->loop == client->loop); > > > > I read the src code and I understand the dependency (mainly around loop) > > between the server and the client so I wanted to know if there is > > a workaround ? > > No. > > libuv is not concurrency safe. You cannot access a uv_loop_t or > anything that's associated with it (uv_req_t, uv_handle_t, etc.) > simultaneously from multiple threads. > > libuv is not thread safe either. Even with proper locking in place, > using libuv structures from multiple threads is not safe. That's > mostly a uv-win limitation but uv-unix doesn't make any guarantees > either. > > > BTW I thought that maybe I could use memcpy on uv_stream_t and assign > the > > new loop to server variable, but I have no idea if the struct will be > > correctly copied and if it won't introduce more problems. Do you know if > > there is a method to copy and move uv_stream_t between loops properly? > > Not at the moment. We used to support it when we were working on > isolates support in node. When isolates got dropped, we dropped that > feature from libuv as well. > > If you have a strong need for such a feature, open an issue at > https://github.com/joyent/libuv/issues (and please explain your use > case.) > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
