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!
Yep, my sample app uses SO_REUSEPORT. Note however that while BSDs also
have SO_REUSEPORT it does a different thing. Only Linux (>= 3.7 or 3.9
IIRC) has the load balancing behavior.
> 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.
Yes, because the queue is not accessed from multiple threads. That
implementation is not thread safe.
> 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
<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.
Maybe it got backported? No idea, AFAIK it appeared on 3.7 or 3.9. It
used to work, though it may require an adjustment or 2 :-) At any rate
is more of a toy example than a functioning one...
Cheers,
--
Saúl Ibarra Corretgé
http://bettercallsaghul.com
--
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.
