pid1: rework how we dispatch SIGCHLD and other signals
authorLennart Poettering <lennart@poettering.net>
Tue, 23 Jan 2018 17:18:13 +0000 (18:18 +0100)
committerLennart Poettering <lennart@poettering.net>
Tue, 23 Jan 2018 17:41:40 +0000 (18:41 +0100)
commit575b300b795b6765d66e0f351d80635c7d3addea
tree0c14d5e6d038bd23b9bc1770d1f974d362c20eda
parent67ae4e8d599636ed3bb907733476e927496a1d07
pid1: rework how we dispatch SIGCHLD and other signals

This fundamentally makes one change: we never process more than one
signal or more than one waitid() event per event loop. We'll never tight
loop around waitid() or around read() on our signalfd instead, but
always return to the main event loop after processing one event.

By doing this we put the event priorization handling into full power
again, as we'll always check for higher priority events before looking
at the next signal or waitid() again.

This introduces a new "defer" event source "sigchld_event". It's enabled
as soon as we see SIGCHLD, and disabled as soon as waitid() reported no
further children pending. It's running at a relatively high priority,
one step higher than signal handling itself, but lower than
/proc/self/mountinfo event handling, so that the latter always takes
precedence.

Since we want to process sd_notify() events at an even higher priority
than SIGCHLD (as before) it is moved one priority step up, too.

Fixes: #7932
Possibly fixes: #7966
src/core/manager.c
src/core/manager.h