Re: igc, macOS avoiding signals

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 02 Jan 2025 12:34:58 +0000
> From: Pip Cet <pipcet@protonmail.com>
> Cc: Stefan Kangas <stefankangas@gmail.com>, gerd.moellmann@gmail.com, eller.helmut@gmail.com, emacs-devel@gnu.org
> 
> > We don't know the answer, AFAIU.  We could tell them that if they
> > prefer a patch, we can send one.
> 
> I see no requirement to modify MPS, so far.

There's no requirement, but it would be silly, IMO, to try to solve
these issues without ever talking to the MPS developers.  We have
nothing to lose, but it's possible that they will point out other
solutions.  Why give up that up front?  It makes no sense to me.

> The current solution should work fine for Emacs once the special-casing
> of fast symbol handlers, which Helmut is working on IIUC, is in place.

Another pair (or several pairs) of eyes, and by people who know more
than we do about the library, cannot do any harm.  We can always
decide to go our way, regardless.

> >> If we do decide to contact them, I'm afraid that I don't have sufficient
> >> context to accurately describe the proposed callback.  I would need to
> >> ask someone to summarize the idea in sufficient detail so that we can
> >> start a conversation.
> >
> > The problem is that evidently (at least on Posix platforms), if a
> > program that uses MPS runs application code from a SIGPROF or a
> > SIGALRM or a SIGCHLD signal handler can trigger a recursive access to
> > the MPS arena,
> 
> Let's be specific here: it's about accessing MPS memory, not about
> allocating memory.

I agree.  But then I didn't say anything about allocations.

> > which causes a fatal signal if that happens while MPS
> > holds the arena lock.
> 
> I don't know what "fatal signal" is supposed ot mean in this case, to
> the MPS folks.

It's an accepted terminology, but we could explain if needed.  My text
was for Stefan (who does know what "fatal signal" means), not for
quoting it verbatim in a message to MPS.

> > So we want to ask for a callback when MPS is
> > about to lock the arena, and another callback immediately after it
> > releases the lock.
> 
> That's the first time I hear about the "about to lock the arena"
> callback.  Wouldn't hurt, of course, but it's also a new idea.

It was always the idea.

> "Immediately", of course, may be misleading: if another thread is
> waiting for the lock, the lock will not be available until that thread
> is done with it.

Which other thread?  There can be only one Lisp thread running at any
given time.

> There's a third lock operation, of course: _trylock, used for
> (invasively) checking whether a mutex is currently available.  Do we
> want a pair of callbacks for that, or a third callback, or nothing at
> all?

I think these questions are ahead of time.  We should first hear what
the MPS developers think about this idea.

> We could block the appropriate signals before (in some cases, quite a
> while before) we take the arena lock and unblock them after we release
> it.  That's not obviously the best solution, but it's the only one this
> change would enable, AFAICS.

The problem is, we don't know when the arena will be locked, thus the
request for a callback.

> > Alternatively, if MPS already has a solution for such applications
> > that use signals, we'd like to hear what they suggest.
> 
> That's a useful question to ask, of course.  My understanding is that
> MPS is configured mostly at build time, and your idea would amount to
> creating a replacement for lockix.c and lockw3.c which allows blocking
> signals.

Once again, let's hear what the MPS developers have to say about that.

> > As background, you can point them to this discussion:
> >
> >   https://lists.gnu.org/archive/html/emacs-devel/2024-06/msg00568.html
> 
> I think the polite thing to do would be to agree on a short but accurate
> summary of what it is we want, explaining why it would be helpful (it
> may simplify things but isn't required for correctness).

That discussion has several backtraces which might be useful for them
to better understand the issue.