[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MPS: a random backtrace while toying with gdb
From: |
Helmut Eller |
Subject: |
Re: MPS: a random backtrace while toying with gdb |
Date: |
Sun, 30 Jun 2024 12:24:58 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
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.
- Re: MPS: a random backtrace while toying with gdb, (continued)
- 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, 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, 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, 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, 2024/06/30
- Re: MPS: a random backtrace while toying with gdb, Helmut Eller, 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,
Helmut Eller <=
- Re: MPS: a random backtrace while toying with gdb, Eli Zaretskii, 2024/06/30
- 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