Author gvanrossum
Recipients gvanrossum, martius, neologix, vstinner, yselivanov
Date 2015-05-26.16:49:31
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432658972.03.0.408560515652.issue21998@psf.upfronthosting.co.za>
In-reply-to
Content
I think only (3) is reasonable -- raise RuntimeError. There are too many use cases to consider and the behavior of the selectors seems to vary as well. Apps should ideally not fork with an event loop open; the only reasonable thing to do after a fork with an event loop open is to exec another binary (hopefully closing FDs using close-on-exec).

*Perhaps* it's possible to safely release some resources used by a loop after a fork but I'm skeptical even of that. Opportunistically closing the FDs used for the self-pipe and the selector seems fine (whatever is safe could be done the first time the loop is touched after the fork, just before raising RuntimeError).
History
Date User Action Args
2015-05-26 16:49:32gvanrossumsetrecipients: + gvanrossum, vstinner, neologix, yselivanov, martius
2015-05-26 16:49:32gvanrossumsetmessageid: <1432658972.03.0.408560515652.issue21998@psf.upfronthosting.co.za>
2015-05-26 16:49:32gvanrossumlinkissue21998 messages
2015-05-26 16:49:31gvanrossumcreate