On Fri, Apr 22, 2016 at 12:17 AM, Saúl Ibarra Corretgé <
sag...@gmail.com> wrote:
> I went through those issues quickly, and from the top of my head, I'd
> say this is what you can attempt to do:
>
> - fix the broken global state after forking (IIRC it's just a signal
> pipe and the threadpool)
Also the fsevents thread on OS X. I don't know how well-behaved
fsevents is in the presence of forking.
> - destroy the loop and recreate it in the child, re-creating all
> necessary watchers.
Jason, how do you plan to deal with file descriptors that are watched
in parent and child both? It's essentially indeterminate which
process is going to receive the events. That's possibly okay (and, I
suspect, in your case intentional) for listen sockets but it breaks
anything that does read/write operations, like regular sockets.
Duplicating file descriptors won't help because epoll, for example,
reports events for file descriptions, not file descriptors. A nasty
consequence is that you can get events for file descriptors that have
been closed in your process but are still alive in other processes;
the stdio file descriptors are prime examples.
Tangential aside: In node.js we found that, at least on Linux and
Solaris, polling a listen socket from multiple processes or threads
results in very unevenly distributed loads; most of the connections
end up in one or two "favored" (by the system scheduler)
processes/threads.
I wound up rewriting the cluster module (node's multiprocessing
equivalent) in round-robin fashion to fix (well, "fix") that. Newer
kernels allegedly fare better but in my limited testing, the
distribution still isn't very fair.