Hi all, On Thursday, 21 April 2016 17:17:12 UTC-5, Saúl Ibarra Corretgé wrote: > > > Great work taking over the maintenance of > Gevent, I like gevent myself and attempted to do this in the past [0] > though it was mostly a test, so I'm really happy to see interest in > getting libuv into gevent. > > Thanks! I did come across that when I was researching libuv and prior art in this area. I noticed that it (of course) ran into the same problems I have.
> > > > > > > TL;DR: I'm willing to write code to help libuv survive a fork() (I can > easily test on OS X and Linux). But before I start, would the maintainers > be willing to accept such a patch? I realize that libuv strives to be fully > cross-platform, and I also realize that similar issues have been brought up > before (e.g., [2], [3]), but I didn't find anywhere that specifically said > "no way." There are multiple approaches that could work for gevent, > everything from a libev-style 'uv_loop_fork()' call where all the watchers > survive (obviously ideal from my point of view, especially if fork watchers > got added too :), to simply terminating the loop in the child and letting > gevent create a new loop and watchers. If this is something the maintainers > are interested in, I look forward to working together to find the best > approach. (And if this is best discussed in another venue like a github > issue or IRC I'm happy to continue there.) > > > > 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) > - destroy the loop and recreate it in the child, re-creating all > necessary watchers. > > The last part could be tricky because you'd need to dup all fds you want > to reuse (I guess) and close everything nicely in the child. > > (libev doesn't dup the descriptors at fork, and it's not clear to me why you'd want to...) > This *could* work, but I guess the only way to know is to put up the > sleeves and give it a go. > > libev makes it look relatively easy, and I'm sure anything libev can do, libuv can do at least as well :) Unless there is strong opposition from other maintainers, I'd say go > sketch up some APIs and open an issue/PR so we start discussing the > code/design. > Cool! I've started by putting together some failing test cases (probably initially mostly reflecting the things gevent already does with libev and forking) and next I'll try to play around with some ideas for fixing them so that (a) I'm sure it's at least possible and (b) I have a better idea what I'm talking about when I go to open an issue/PR. Thanks again, 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.
