Paul Eggert wrote:
> > Hm? I don't understand. The goal being to avoid that a SIGINT signal being
> > handled by a thread other than the current thread, how can a spin lock help
> > doing that?
> > If you mean to install a certain SIGINT handler, how do you imagine that
> > handler to look like?
>
> Well, perhaps I'm not understanding the situation correctly, but from
> the brief description of what fatal-error does it seems to me that it
> could use a static pthread_t variable T containing the identity of the
> thread that should handle SIGINT. If the signal handler fires off in
> some thread other than T, the handler merely uses pthread_kill to
> forward SIGINT to T.
>
> Setters and getters of T can be protected both by blocking SIGINT (to
> make them async-signal-safe) and by a spin lock (to make them
> thread-safe). The pattern should be block, lock, do the work, unlock,
> unblock. If the signal is known to be already blocked (e.g., the
> pattern's called from a SIGINT handler established without SA_NODEFER),
> the pattern can skip the block and unblock steps.
I see. Thanks for explaining. This is for the "redirect the signal to
the desired thread" approach, which we find
- in emacs/src/sysdep.c, as you say,
- in poke/poke/pk-repl.c.
I think for 'fatal-signal' I'll prefer the sigdelay approach, because
- In this case, we don't need the signal handler to execute within
a particular thread (the signal handler's job is to delete some
temporary files).
- Thus no variable T is needed.
- It's more robust in situations where the process creates short-lived
threads. (AFAIU there is a race condition between the signal delivery
and the thread termination.)
- We don't have pthread_kill on native Windows.
Bruno
