Re: Some experience with the igc branch

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sun, 29 Dec 2024 12:39:53 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, eller.helmut@gmail.com, acorallo@gnu.org
> 
> >> Instead, we call the SIGSEGV handler directly on the other thread,
> >> passing in the same siginfo structure.
> >
> > How can we call the SIGSEGV handler directly from another thread?  And
> 
> It's a C function.  We call it.

We need to know its name or its address to do that.  It is not our
function.

> > how will that thread know it needs to call the handler in the first
> > place?
> 
> We'd like to just use pthread_cond_signal, but to be POSIXly correct we
> need to do so from another thread.

Ouch!

> >> > how will it know which MPS function to call?
> >>
> >> The MPS SIGSEGV handler is obtained by calling sigaction.
> >
> > That's unreliable: it assumes that no one else calls sigaction after
> > MPS, or changes the chain of handlers in some other way.
> 
> It merely assumes that any such modifications call our signal handler
> with the right arguments, which is precisely what MPS assumes anyway.

Sorry, I don't follow.  We need to know the address of the handler
before the signal happens, no?  So how calling our handler is
relevant?

> > Also, on MS-Windows MPS doesn't use a signal handler (because there
> > are no signals on Windows, really).  It uses an exception handler, and
> 
> Can exception handlers be interrupted by emulated signals running on the
> same stack?

Emulated signals cannot possibly run in the same thread, because they
must be asynchronous events.