On Tuesday, October 18, 2016 at 7:23:54 AM UTC+2, Saúl Ibarra Corretgé 
wrote:
>
> 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.


[snip]
 

> 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.

Cheers, 
> 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