Re: scratch/igc: Avoid MPS being interrupted by signals

[Pip Cet]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> As I mentioned, I reverted
>
>   ceec5ace134 * Avoid MPS being interrupted by signals
>
> in my fork because I observed worse "smoothness" in interactive use on
> macOS.

Eli said Helmut was working on fixing this commit for SIGIO/SIGPOLL,
which is most likely the problem (and implied I shouldn't work on that,
of course, because Eli).  OTOH, if we just fix the few remaining
handlers, it's safe to remove it.

> Is this commit still strictly necessary on non-macOS now that

I don't understand why you think this differs between macOS and
non-macOS.  The way macOS handles SIGSEGV does not make things any
safer: if a signal handler accesses MPS data we lose on any platform.

That said, there aren't that many signal handlers.  Definitely SIGINT
(accesses terminal data), technically SIGUSR (accesses symbol, string,
string data), probably more on Windows and Android.

> Helmut's changes for SIGPROF are in?

Helmut's changes for SIGPROF and SIGCHLD were present before that
commit.  They make SIGPROF safe, but discard data when igc_busy_p (),
which has false positives.  I don't understand why SIGCHLD needs a
fixed-size queue and function pointers rather than simply setting a
flag, but what it does now is safe.

igc_busy_p () uses pthread_trylock, but that seems safe on glibc.

> If not, I'd like to reverse it on scratch/igc.

I don't know what you decided wrt scratch/igc and Eli.  If we really
want to spend more time on signal handling we can remove it and fix the
remaining handlers; if we don't, special-case safe signals and leave it
in.

Pip