Re: Dynamic modules: MODULE_HANDLE_SIGNALS etc.

[Paul Eggert]

Daniel Colascione wrote:
> The quick and dirty fix for Fdo_auto_save is to run
> Fdo_auto_save in a forked child, where it's less likely to hurt
> something, and put a limit on the time we're prepared to spend waiting
> for that child.

fork isn't async-signal-unsafe in glibc, so it's not clear this is safer there. 
Also, even assuming POSIX compliance, suppose a library establishes an 
async-signal-unsafe handler via pthread_atfork? Either way, although the 
quick-and-dirty fix could be better than what we have now, it also could be worse.

See:

https://sourceware.org/bugzilla/show_bug.cgi?id=4737