emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MPS: a random backtrace while toying with gdb


From: Gerd Möllmann
Subject: Re: MPS: a random backtrace while toying with gdb
Date: Sun, 30 Jun 2024 13:07:23 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Helmut Eller <eller.helmut@gmail.com> writes:

> On Sun, Jun 30 2024, Eli Zaretskii wrote:
>
>>> I would move most of the work out of signal handlers.  The signal
>>> handler could put the work in a "async work queue" and then return.  The
>>> actual work is then processed by maybe_quit.
>>
>> But in this case we hit the barrier just by accessing the process
>> object.  How can you do anything useful in a SIGCHLD handler if you
>> cannot even find out which process exited and how did it exit?
>
> You don't do anything useful other than packing up the arguments that
> the signal handler receives and put them in the queue.
>
>> Surely, something like that is needed in order to put any work on some
>> queue?  And I'm not even talking about the effects of deferring this
>> job "for later" on the speed of working with sub-processes in Emacs.
>
> The queue is not in MPS-managed memory; so we can access it.
>
>> IMO, we must find a way of touching MPS-managed memory safely from a
>> signal handler, otherwise writing signal handlers will become an
>> impossible job.
>
> The MPS documentation says quite clearly that a scanner must not access
> MPS-managed memory other than the block it receives as argument:
>
>   
> https://memory-pool-system.readthedocs.io/en/latest/topic/format.html#cautions
>
> 5. Format methods must not:
>
>    a. call library code;
>    b. access MPS-managed memory in pools that protect their contents;
>    c. perform a non-local exit (for example, by throwing an exception, or
>       calling longjmp());
>    d. call any functions or macros in the MPS other than
>       MPS_SCAN_BEGIN, MPS_SCAN_END, MPS_FIX1(), MPS_FIX12(), MPS_FIX2(), and
>       MPS_FIX_CALL.
>
>    It’s permissible to call other functions in the client program, but
>    see MPS_FIX_CALL for a restriction on passing the scan state.
>
> 6. Subject to the above constraints, format methods can freely access:
>
>    a. memory inside the object or block that they have been asked to
>       look at;
>    b. MPS-managed memory in pools that do not protect their contents;
>    c. memory not managed by the MPS.

Amen! That's how I see it too.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]