Signal handling fixes

[alebastr]

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

[ShellCode33]

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

	void UnixSignalHandler::start() {
	// Block signals so they can be handled by the signal thread
	// Any threads created by this one (the main thread) should not
	// modify their signal mask to unblock the handled signals
	if (int err = pthread_sigmask(SIG_BLOCK, &mask_, nullptr); err != 0) {
	spdlog::error("pthread_sigmask failed in UnixSignalHandler::start: {}", strerror(err));
	exit(1);
	}
	running_ = true;
	thread_ = std::thread([this]() { run(); });
	}

Even though that will probably work most of the time, you unfortunately cannot do that, pthread_create is not async-signal-safe. You might end up with users reporting bugs that are extremely complex to diagnose.

You can have a look at man 7 signal-safety for a list of functions you can call in a signal handler.
Some pthread functions are there:

pthread_kill(3)        Added in POSIX.1-2008 TC1
pthread_self(3)        Added in POSIX.1-2008 TC1
pthread_sigmask(3)     Added in POSIX.1-2008 TC1

But not pthread_create. What people usually do in signal handlers is that they set an atomic boolean (let's say sigusr2_needs_to_be_processed) to true, and handle it in a separate thread that is already running. Once the thread is done handling the signal, it would set sigusr2_needs_to_be_processed back to false.

[alebastr]

I see that you are spawning a new thread in the signal handler:

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 sigtimedwait(2). Not a single line of the new code runs in a signal handler context.

[ShellCode33]

Oh my bad, I misunderstood what's going on then, I'm sorry for wasting your time