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: Eli Zaretskii
Subject: Re: MPS: a random backtrace while toying with gdb
Date: Sun, 30 Jun 2024 13:00:12 +0300

> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Pip Cet <pipcet@protonmail.com>,  Ihor Radchenko <yantar92@posteo.net>,
>  emacs-devel@gnu.org,  Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 30 Jun 2024 11:36:34 +0200
> 
> On Sat, Jun 29 2024, Gerd Möllmann wrote:
> 
> > Someone has an idea what to do with that? And maybe how to reproduce?
> 
> I can reproduce it with
> 
> /src/emacs -Q -batch -eval '(dotimes (_ 100)
>   (start-process "foo" nil "sleep" "0.2")
>   (igc--collect))'
> 
> 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?
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.

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.



reply via email to

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