On Sat, Aug 29, 2015 at 5:44 PM, Andres Freund <and...@anarazel.de> wrote:
> On 2015-08-29 17:33:22 +0200, Shulgin, Oleksandr wrote: > > Probably using SIGUSR2 would be more appropriate, but I'm not sure if > there > > are other extensions out there that might be already using it for some > > other reason (well, I do not know that for SIGUSR1 either). Looking at > the > > current state of affairs in procsignal_sigusr1_handler() makes me believe > > it should be pretty safe to catch the signal like I do. Or is that not > the > > case? > > You can catch signals, but you're not allowed to do a lot from > them. Anything allocating memory, acquiring locks, etc. is out - these > functions aren't reentrant. If you can guarantee that you're not > interrupting any relevant code you can bend those rules, but that's > obviously not the case here. > > Check out the list of async-signal-safe functions at > http://man7.org/linux/man-pages/man7/signal.7.html Good point. There's still hope to set a flag and process it later on. Will have to check if it's possible to stay in the scope of a loaded module though.
