> On Apr 24, 2016, at 03:48, Ben Noordhuis <[email protected]> wrote: > - 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.
I hadn't come across that thread yet. I'll make sure to add a test case. Thanks! > >> - 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. I was (tentatively) planning to completely ignore that and leave it up to the application to handle splitting descriptors appropriately. My reasoning there boils down to "that's how gevent/libev do it now and it works out okay." In the gevent design (presenting synchronous APIs but hiding an event loop under the covers), watchers are started and stopped frequently (every time a blocking API call is entered/exited), so it's highly likely at the time of a fork() that most watchers are stopped and thus not registered with epoll or the like. After the fork, parent and child each continue on with their own work, re-registering watchers that have been partitioned to them or creating new ones. (It's certainly *possible* to have arbitrary other watchers active at a fork() but it's not a recommended pattern and users are cautioned to be very careful.) Jason -- 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.
