Skip to content
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

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Conversation

alebastr
Copy link
Contributor

@alebastr alebastr commented Oct 7, 2024

First draft. Tested on Linux with glibc only.

See individual commit descriptions for details.

TODOs:

  • It should not be necessary to recreate the outputs. But the whole thing has so many races and weird things happen if I keep using the existing output list.
    Time to dig out my old work on reducing the number of wl_display_roundtrips in the code.
  • CssReloadHelper does not handle appearance changes and .reset() on reloads can be optimized.

Fixes: #3344

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Multiple waybars open after resume from dpms off.
1 participant