Re: Some experience with the igc branch

[Pip Cet]

"Stefan Kangas" <stefankangas@gmail.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> I'm coming to all this from a completely different angle. My
>>> understanding is (1) the signal handling/MPS thing, is the only thing
>>> preventing landing in master
>>
>> That's not so.  It is not the only thing we need to figure out and
>> solve before we can consider landing this on master.

While I think we should keep trying for a while, I still think it's
possible we'll just have to conclude that the current approach is the
best we can do for a quick merge.

It's ugly, but the user-visible problems seem manageable.

1. Delayed signals have to wait for the next explicit check for pending
signals.

On GNU/Linux, we could spawn a helper thread to take the arena lock and
release it again, then send a signal back to the main thread so we can
check for pending signal handlers and run them, assuming we're lucky and
the arena is no longer locked.  This exposes quite a few MPS details,
and there's a risk of an unusable Emacs if the helper thread saturates
the CPU.  The price we pay is that once a signal is delayed, all further
signals have to go to the ping-pong thread until the main thread
restores the sigmask, which it cannot do in a signal handler.

2. One flag per signal hard-codes the number of signals usable by Emacs.

I don't think this is a blocker.

3. We restore the "original" sigmask, so changing the sigmask from other
parts of Emacs won't work reliably.  Neither will any checks for whether
a signal is logically blocked, because delayed signals will be masked
once in a while, causing false positives.

This seems fixable, and should be fixed.

>> we have unresolved issues with patches to MPS for some platforms,
>> whereby we considered forking MPS or some other course of actions.
>
> Forking MPS is obviously better to avoid, if at all possible.

Forking MPS on GNU/Linux x86-64, in particular.  I'm not sure how Gerd
feels about macOS.

>> Also, there are several FIXMEs in igc.c itself.
>
> Are all of these important enough to be considered as blockers for
> merging to master, or only some of them?

Very few of them, I think.  My impression is most of them are about the
remaining places where we use ambiguous marking unnecessarily, which we
should fix before concluding MPS slows us down too much, but not
necessarily before we merge.  (However, we should be very, very clear on
that point: mps works now, but it's almost entirely unoptimized.  Code
which relies heavily on GC may be very slow.)

Bytecode stack marking looks like a huge problem in the source code, but
in reality I've never seen a crash because of it.  My proposed fix is to
limit the maximum stack depth of bytecode objects we read, which will
turn a pernicious problem into an obvious one.

And, yes, we should be careful and register all threads with MPS.  This
will slow down things, but I don't know by how much.

That's all I can remember today, pre-grep.  (Which isn't enough for me:
I'd like to take the time to go through the entire diff for this).

> If the latter, how about making a list of the ones that are considered
> blockers, or perhaps just marking them as such in the FIXME comment in
> the source code?

Excellent idea.  As some of the FIXMEs will go away when what is
currently scratch/no-purespace is merged, maybe we should do that first.

Pip