[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.
- Re: MPS: a random backtrace while toying with gdb, (continued)
- Re: MPS: a random backtrace while toying with gdb, Helmut Eller, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Ihor Radchenko, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Ihor Radchenko, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb,
Gerd Möllmann <=
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Pip Cet, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Gerd Möllmann, 2024/06/30