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