On Fri, Apr 22, 2016 at 12:17 AM, Saúl Ibarra Corretgé <[email protected]> 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. -- 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.
