Re: MPS: a random backtrace while toying with gdb

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> Frankly, if this is what we must do, then this branch is not very
> interesting.  Too bad, I thought this was a promising development in
> Emacs.

What about going back to the alternative proposal with setting up signal
masks:

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Pip Cet <pipcet@protonmail.com>
>> ...
>> The main difference between the two approaches, both of which require 
>> meddling with MPS internals, is that if SIGPROF is blocked, it will be 
>> delivered with a delay after the SIGSEGV handler is done running. If the 
>> SIGPROF handler runs and doesn't do "anything unsafe", on the other hand, it 
>> can record the unusable signal but won't get a new one. I don't see a clear 
>> advantage of either, to be honest. Blocking signals, of course, is more 
>> reliable than "just knowing" we won't do anything unsafe.
>
> I simply don't believe MPS is so poorly designed as to disallow
> signals while its own SIGSEGV handler runs.  SIGPROF is just one
> example; there are also SIGALRM, SIGUSR1, SIGUSR2, and maybe others.
> It makes little sense to me to expect MPS to block these signals.  I
> rather expect them to DTRT with those signals.

I am looking at
https://memory-pool-system.readthedocs.io/en/latest/topic/thread.html#thread-interface

And it says that

    In a multi-threaded environment where incremental garbage collection
    is used, threads must be registered with the MPS by calling
    mps_thread_reg() so that the MPS can suspend them as necessary in
    order to have exclusive access to their state.

If my understanding is correct, the situation we have is when MPS is
performing root scan while also receiving another signal. During the
root scan, all other Emacs threads are suspended, and no state changes
are taking place - everything is locked by MPS thread, which is the only
thread running.

Emacs signal handlers are, of course, installed for all the threads. And
since the only thread being running is MPS thread - it will be the one
handling the received signal. And the handler thus cannot run normally,
reaching out to the MPS-managed memory as usual.

So, we should somehow arrange the handler to wait until the MPS scan
finishes and the actual Emacs threads are resumed.
Such waiting should not lose any information as the actual Emacs state
is not going to change during the scan.

The simplest way to do it is setting up a mask for MPS
thread. (Although, we may or may not want to do it for profiler signals
specifically, depending on whether these signals will be queued by the OS
or merged into a single signal before unblocking - merging will make us
loose some samples)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>