-
Notifications
You must be signed in to change notification settings - Fork 416
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revamp signal handling. #1480
base: master
Are you sure you want to change the base?
Revamp signal handling. #1480
Conversation
- Change from signal to sigaction, which is more portable. - Install a handler for SIGPIPE instead of ignoring it, to avoid passing on the ignored status to other programs launched from bspwm. - Use SA_NOCLDWAIT to avoid the need to call waitpid. (NB if waitpid were called in the handler, it would be a good idea to protect errno.) - Declare the "running" global as volatile sig_atomic_t, as recommended for values modified from signal handlers.
Running linux here and everything seems to be working fine with the patch. I needed to add a signal.h include in bspwm.h to build. fwiw, i could not get the original issue to trigger - bash as shell and dash as sxhkd shell. I tried directly in bspwmrc, but no hang with the find command. |
Thanks! Added.
Interesting. I don't have a Linux computer I can run bspwm on, but I do have Linux shell access. I'm curious what these two commands do for you:
On OpenBSD and my Linux shell account, the find command keeps running (and on Linux, writes permission errors to stderr).
Baseline to compare to. Exits right away for me. (Tangent: I tried making Python versions of the above commands in case you have Python more readily available, but as far as I can tell Python's |
The perl commands act as expected, pipe ignore version with perm errors to stderr and normal version exits immediately. Not sure why I'm not getting the sig_ign behavior you get. linux's procfs has bitmasks for the caught/blocked/ignored signals of a process and makes it easy enough to check. Certainly am inheriting the signal handlers from bspwm in bspwmrc and external rules script (sxhkd is not launched from bspwmrc and is not a child of bspwm on my machine) |
I ran into a bug related to bspwm's signal handling, and then noticed a couple of other issues, so decided to try redoing it.
The bug: pipes like
find / | :
would hang when launched from bspwm instead of terminating right away. The reason was that bspwm ignoresSIGPIPE
, and that status got passed on to anything launched viabspwmrc
, throughsxhkdrc
,xterm
, my shell, all the way through to thefind
process which is supposed to die when its output is cut off.NB I've only just started testing this change by using it (edit to add: on OpenBSD, so testing on Linux might be valuable). If there are particular things for me to try out (e.g. the reasons the signal handlers were installed in the first place), let me know.
Details:
Change from signal to sigaction, which is more portable.
Install a handler for SIGPIPE instead of ignoring it, to avoid passing on the ignored status to other programs launched from bspwm.
Use SA_NOCLDWAIT to avoid the need to call waitpid. (NB if waitpid were called in the handler, it would be a good idea to protect errno.)
Declare the "running" global as volatile sig_atomic_t, as recommended for values modified from signal handlers.