Ngninx/Stud fork()s and the child runs the event loop; the parent just does a bind(). Since stud uses libev you can also look at the implementation in stud:
https://github.com/bumptech/stud/blob/master/stud.c#L1822 https://github.com/bumptech/stud/blob/master/stud.c#L1853 https://github.com/bumptech/stud/blob/master/stud.c#L1613 https://github.com/bumptech/stud/blob/master/stud.c#L1515 On Wed, Aug 29, 2012 at 2:45 PM, Zhang Hu <[email protected]> wrote: > Hi Mathieu, > > I'm thinking the same problem as you had. If I'm right, nginx's > work-thread machnism can benifit the multiple CPUs/cores. Nginx listens one > sockets by multiple processes. > > How is your solution doing? > > Regards, > Tiger > > > On Monday, July 2, 2012 4:28:13 PM UTC+8, Mathieu Garaud wrote: > >> Hi, >> >> Thanks for the tip! I'll implement this solution this evening and I'll >> see if I'm able to increase the number of request/s of this HTTP server can >> handle. >> >> Cheers, >> >> Mathieu >> >> On Monday, July 2, 2012 3:05:45 AM UTC+2, Ben Noordhuis wrote: >> >>> On Mon, Jul 2, 2012 at 1:39 AM, Mathieu Garaud <[email protected]> >>> wrote: >>> > 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. >>> >>> I'm afraid there's no convenient support for in-process sharing of >>> handles at the moment. What can you do is the following (I'm assuming >>> you have some kind of TCP server that you want to share across >>> threads): >>> >>> 1. (thread A) create your uv_tcp_t server handle (i.e. bind and listen) >>> 2. (thread A) create a uv_pipe_t and bind it to a path. >>> 3. (thread B) connect to the pipe >>> 4. (thread A) send over the server handle with uv_write2() >>> 5. (thread B) receive handle and start listening >>> >>> Does this work well if there are more threads? Will the threads not contest with each other for performing an accept() if there is an event loop per thread listening for incoming connections? Or am I missing something? > In case you're interested, [1] is the commit that removed uv_import() >>> and uv_export(). In hindsight, it may have been better to leave them >>> in. >>> >>> Then again, the approach outlined above works and has the benefit that >>> it's intrinsically thread-safe - all the hard work is done by the >>> operating system. >>> >>> [1] >>> https://github.com/joyent/**libuv/commit/c5aa86b<https://github.com/joyent/libuv/commit/c5aa86b> >>> >> -- > 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 > -- 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
