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:06:40 +0200
User-agent: Gnus/5.13 (Gnus v5.13)

Eli Zaretskii <eliz@gnu.org> writes:

>> 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.

FWIW, I disagree but I guess that was already clear.



reply via email to

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