Block SIGUSR1

Ignoring the signal makes it end up in the wrong thread sometimes (see commit message for details).

Closes #20 (closed)

WIP since it depends on !12 (merged)

added 1 commit

• 9991ca5b - main: Block SIGUSR1 instead of ignoring it

Compare with previous version

added 1 commit

• 04acc677 - main: Block SIGUSR1 instead of ignoring it

Compare with previous version

mentioned in merge request !15 (merged)

mentioned in merge request phosh!191 (closed)

added 2 commits

• 3d34a6e0 - 1 commit from branch Librem5:master
• c56531b1 - main: Block SIGUSR1 instead of ignoring it

Compare with previous version

unmarked as a Work In Progress

changed the description

Rebased the MR now it's dependency is in.

I'm not sure I understand the significance of this. Does blocking the signal in this thread ensure that it goes to a different thread instead?

Yes: https://github.com/wayland-project/wayland/blob/master/src/event-loop.c#L351 also check

man 7 signal

The man page doesn't really tell me much, but I conjecture that when a signal is blocked, then it's deferred, and it goes to another thread if possible. Since the main thread blocked it beforehand, then the other available thread will be the one which explicitly unblocked the signal, which is xwayland.

Is that right? The dance is not obvious, can we put a few more details somewhere near the change?

Doesn't the commit message have all the details?

After reading the comment, searching the web, and searching through the man page, it still wasn't clear to me what the important difference between blocking and ignoring was. If you didn't confirm, I would still not be sure if my guess was right.

https://www.gnu.org/software/libc/manual/html_node/Blocking-Signals.html

In this case we block it in all threads except one so the signal ends up being processed there.

I wouldn't mind it if I was the only person to ask that question, but I think it's going to be useful to have some more info to save the searching for whoever comes to maintain it next.

added 1 commit

• adc7752f - main: Block SIGUSR1 instead of ignoring it

Compare with previous version

Then I need to know what else you expect. Someone looking at this would go

git blame
git show adc7752f2526737756ccfedf7ce2dfaeeec35791

Then look at wl_event_loop_add_signal() documentation and see what the function's requirements are (and these are also written down in the commit message.

I noticed a missing 'but' in the commit message. I guess it's clearer now.

added 1 commit

• b9ba9bd4 - main: Block SIGUSR1 instead of ignoring it

Compare with previous version

You're right, I think I just brainfarted.

merged