Re: Some experience with the igc branch

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Sun, 22 Dec 2024 22:26:11 +0000
>> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org,
>>  Helmut Eller <eller.helmut@gmail.com>, Andrea Corallo <acorallo@gnu.org>
>> From:  Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>
>>
>> >> 1. The signal issue.  I don't have a good way to fix this and make
>> >> everyone happy, but I do have a solution which hasn't caused a crash for
>> >> me in quite a while.  It may be good enough.
>> >
>> > TBH, I'd have put it in already.
>>
>> Pushed it now.  It is imperfect, but better than crashing.
>
> Why didn't we discuss this with MPS folks?  A program can legitimately

Because...

> call some code from a signal handler, so the limitations that MPS
> seems to impose now are not very reasonable.  Maybe we are missing

...if they were interested, maybe they've read this or some other
blanket accusation of being "unreasonable", and became uninterested
quickly.  I know I would.

> some feature, or maybe the MPS folks will agree to extend the library
> to provide better support for programs that use signals.  E.g., AFAIU
> with this code installed, we are limiting our profiler too much (it
> will never report GC, IIRC?).  I think igc_busy_p returns non-zero in
> too many situations where delivering signals could not possibly cause
> harm, like during object allocation, AFAIR.  According to
> documentation, that function is not intended for this kind of purpose.
>
> IOW, we had discussions about this which never concluded anything, and
> we should pick up where we left off and solve this problem.

I have a different idea using a separate allocation thread (for the slow
path only, of course).  Would that be potentially acceptable?

It would limit MPS to systems providing a working atomic.h header, and
in practice also require some sort of working (and reasonably fast)
inter-thread signalling (though I suspect it'd be faster to run both
threads on the same core, since it's a handover rather than a
parallelism situation).  That excludes very few systems these days
(sorry, MS-DOS).

I'll spare you most of the details for now, but having read the mps
header, MPS allocation is not safe to use from separate threads without
locking the AP (or having per-thread APs), which we might end up doing
on Windows, IIRC.  I'd rather give those (potential) issues a wide
berth.  Also, by the campsite rule, merging MPS shouldn't make it harder
to move in the direction of multi-threaded Emacs.

Better debugging (which I agree with you is something we need to
improve), no MPS modification.  Performance implications TBD.

> We should definitely try improving this before we land the branch on
> master.  We shouldn't consider this solution "good enough", but just a
> temporary kludge meant to avoid too frequent crashes.

Agreed.

Pip