2015-08-29 18:25 GMT+02:00 Shulgin, Oleksandr <oleksandr.shul...@zalando.de> :
> 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. > I had a workable prototype - and It was implemented very similar as handling CANCEL Pavel
