On Tuesday, October 18, 2016 at 7:23:54 AM UTC+2, Saúl Ibarra Corretgé 
> On 17/10/16 19:41, Gonzalo Diethelm wrote: 
> > First post, libuv newbie.
> Hi and welcome to libuv then! 

Thanks, and thank you for your thorough response.

> > I am trying to understand how a multi-threaded web server would fit in 
> > the libuv design. This is how I envision it, but I have some questions.


> If each thread is a uv loop, then you could send the connection where 
> the request came from from one loop to another using uv_write2.  That 
> way the job of the "acceptor loop" would only be accepting and 
> dispatching connections.

That's a great suggestion. This is not how you implemented things in your 
example, right? I believe there each worker accepts its own connections and 
processes everything from there on. I didn't know you could do the accept 
in separate threads... Ah, the magic of SO_REUSEPORT? That makes things 
even easier!

> 1. Is using a thread-safe queue a good match for libuv? If libuv 
> > provides something like this, I have not been able to find it, and that 
> > makes me doubt this would be the libuv way.
> For certain scenarios such a construct would be useful, we don't provide 
> it though.  Have a loop at http://concurrencykit.org/ 

I see in your example you instead used QUEUE; I guess that's enough for 
these purposes.

> > 2. Is it possible / advisable to have multiple threads in a process, 
> > each handling I/O with its own libuv loop? I guess yes.
> Yep. Nginx (which doesn't use libuv) uses a similar model. 

Thanks for confirming this.

> In case it helps, I created a multi-threaded HTTP server prototype to 
> try out some stuff here: https://github.com/saghul/uttp It currently 
> uses SO_REUSEPORT for kernel level connection balancing in Linux and the 
> NOTES file https://github.com/saghul/uttp/blob/master/NOTES contains the 
> other strategies I was going to try but never found the time :-) 
> I hope you find it useful. 

This is very useful indeed, thanks much!

One thing is that when I control-C out of the running server, it prints the 
following and then hangs:
^C[INFO] (../src/server.c:16) Received SIGINT, stopping...
[INFO] (../src/server.c:107) Stopping workers...
[INFO] (../src/worker.c:81) [Worker #0] stopped
[INFO] (../src/worker.c:81) [Worker #1] stopped
[INFO] (../src/worker.c:81) [Worker #3] stopped
[INFO] (../src/worker.c:81) [Worker #2] stopped 

I have to kill -9 the process to terminate it. This is on CentOS 6.8 using 
kernel 2.6.32 (hangs head in shame...). Perhaps too old to support 
SO_REUSEPORT? The #define is there and the compilation doesn't throw any 
warnings, but there.

> Saúl Ibarra Corretgé 

Again, thanks for all the help. Cheers.

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 libuv+unsubscr...@googlegroups.com.
To post to this group, send email to libuv@googlegroups.com.
Visit this group at https://groups.google.com/group/libuv.
For more options, visit https://groups.google.com/d/optout.

Reply via email to