It seems like what you want is... another arbitrary patch atop the mess! Specifically, a rule that unblocked signals which have open signalfds act exactly as if blocked (pending signals being sent down the signalfd 'instead' of being conventionally delivered) until the fd is closed. Now, assuming that the user has opened the signalfd O_CLOEXEC (hey, that should be the default! but we repeat ourselves), the signal will automatically 'unblock itself' at exec() time, which is exactly what we want.
Bonus: no change to signal semantics when signalfd is not in use, and nobody sane would want the current semantics in any case.
Posted Nov 17, 2010 14:43 UTC (Wed) by madcoder (subscriber, #30027)
[Link]
No, you want a real atfork() interface that is not related to threads. pthread_atfork is here because when you fork() from threads, you fork one new process, not "all the threads" and that often means that you have to deregister stuff.
Anyway, there is a solution for that (which is messy butÂ…) on linux which is to redefine fork(), system(), pthread_spawn{,p} and every similar problematic fork() wrapper using dlsym chaining to reset your signal masks properly. This isn't *that* complicated, and chains nicely. Or if you're sure that pthread_atfork() works for some then only divert the ones where it doesn't. I know it's not portable but signalfd() isn't in the first place either ;)
WRT clone() I'd say that this is a very low level interface which has a really high chance to break the libc when used (e.g. TSD breaks in interesting ways in the glibc if you use clone without emulating what the glibc does IIRC), so I'd say people using it Know What They Are Doing in the first place and should have worried about resetting the signal mask to a sane default in the first place.