fish's signal handlers are now sufficiently innocuous that there should
be no reason to block signals (outside of temporarily, when creating a
thread and we need to manipulate the signal mask).
Prior to this fix, an "event" was used as both a predicate on which events
to match, and also as the event itself. Re-express these concepts
distinctly: an event is something that happened, an event_handler is the
predicate and name of the function to execute.
Prior to this fix, fish had a signal_list_t that accumulated signals.
Signals were added to an array of integers, with an overflow flag.
The event machinery would attempt to atomically "swap in" the other list.
After this fix, there is a single list of pending signal events, as an array
of atomic booleans. The signal handler sets the boolean corresponding to its
signal.
In a galaxy far, far away, event_blockage_t was intended to block only cetain
events. But it always just blocked everything. Eliminate the event block
mask.
Arch changed the version string to include the package rel, so it
looks like
systemd 241 (241.7-2-arch)
which would break our simple `string replace` and `test`.
Fixes#5689.
[ci skip]
This was treated as a glob where it was still enabled, most likely removing the "-E" option from argparse,
which caused `sudo -E` to not be parsed correctly, breaking completion.
(There was no error because the glob was used with `set`)
Fixes#5675.
[ci skip]
As it turns out, NetBSD's rand(3) is awful - it's possible that in any
given run it'll only return odd numbers, which means
while (rand() % 10)
will never stop.
Since random(3) is also standardized and works, let's use that!
This commit merges support for a new event publishing mechanism
"topic_monitor" that allow for waiting on multiple event types. It then
replaces waitpid() logic inside `process_mark_finished_children` with new
and simpler logic built around this mechanims. Lastly it migrates the
builtin and function output from processes to background threads.
