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).