-
-
Notifications
You must be signed in to change notification settings - Fork 720
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
Signal handling fixes #3669
base: master
Are you sure you want to change the base?
Signal handling fixes #3669
Conversation
The previous implementation was not async-signal-safe and could cause lots of hard to debug issues. The common ways to handle that include * Self-pipe and non-allocating lock-free set of pending signals in the main thread (see `g_unix_signal_source_new` for example). * A dedicated signal handling thread calling `sigtimedwait`. * Linux-specific solution with `signalfd(2)`. * FreeBSD-specific solution with `EVFILT_SIGNAL` filter for `kqueue`. `GUnixSignalSource` intentionally supports a very limited set of signals, making it a bad fit for us. There's also no benefit in maintaining a set of platform-dependent solutions. Therefore, extending an existing `signalThread` code seems to be the best option. All the threads and child processes inherit the signal mask we set in `UnixSignalHandler::start()`, and now we block a few more signals. That requires an extra care when forking and starting new processes. Thankfully, `waybar::util::command` already does everything necessary and appears to be used consistently across the source.
Repeated calls to `Client::main()` result in unnecessary work and duplication of several event handlers. A common consequence of that is the bug with multiple bars being created (Alexays#3344). This change ensures that the `main` is called only once and makes reload logic much simpler.
Hi, I'm coming from #3344. Thanks for your work on this! I see that you are spawning a new thread in the signal handler: Waybar/src/util/unix_signal.cpp Lines 48 to 59 in d8a7f42
Even though that will probably work most of the time, you unfortunately cannot do that, You can have a look at
But not |
That's not what is happening here. The signal handling thread is started from the main thread in normal context, then we mask all the signals that are interesting for us for all the application threads and listen for signals with |
Oh my bad, I misunderstood what's going on then, I'm sorry for wasting your time |
First draft. Tested on Linux with glibc only.
See individual commit descriptions for details.
TODOs:
Time to dig out my old work on reducing the number of
wl_display_roundtrip
s in the code.CssReloadHelper
does not handle appearance changes and.reset()
on reloads can be optimized.Fixes: #3344