Re: SIGPROF + SIGCHLD and igc

[Helmut Eller <eller.helmut@gmail.com>]

On Sun, Dec 29 2024, Eli Zaretskii wrote:

1>> From: Helmut Eller <eller.helmut@gmail.com>
>> Cc: gerd.moellmann@gmail.com,  pipcet@protonmail.com,  ofv@wanadoo.es,
>>   emacs-devel@gnu.org,  acorallo@gnu.org
>> Date: Sun, 29 Dec 2024 20:34:11 +0100
>> 
>> On Sun, Dec 29 2024, Eli Zaretskii wrote:
>> 
>> >> Here another observation: Let's assume that we can emulate SuspendThread
>> >> and ResumeThread on POSIX and MacOS (much like MPS does it).  In the
>> >> profiler thread we can then simply do:
>> >> 
>> >>    SuspendThread (<main-thread>)
>> >>    get_backtrace ()
>> >>    ResumeThread (<main-thread>)
>> >> 
>> >> without invoking any SIGPROF handler or the need for
>> >> ArenaEnter/ArenaLeave.
>> >
>> > Yes, we can.  But that means changing what the SIGPROF handler does
>> > will have no effect, which is bad for maintenance.  By contrast, the
>> > current MS-Windows implementation does basically the same, but it
>> > calls the handler, not its body.
>> >
>> > Also, I don't quite see why you thing calling get_backtrace directly
>> > will have any effect on the need to lock the arena.  I'm probably
>> > missing something.
>> 
>> Ok. The arena lock is a problem.  Is that also a problem for the Windows
>> implementation?  How does it avoid deadlocks when the thread holds the
>> arena lock?
>
> You mean, when the SIGPROF handler is called by the thread which
> simulates the SIGPROF signal?

Yes.

> The handler is called in the context of
> the signaling thread, not in the context of the (suspended) Lisp
> thread.

I thought the possibility that the suspended Lisp thread holds the arena
requires extra care on Windows.  But I realize now, that that would be a
problem even if the handler is executed in the context of the Lisp
thread (as on POSIX).  So there is no extra problem on Windows.

>> >> The only complication seems to be, that we must avoid deadlocks when MPS
>> >> tries to suspend a thread is already suspended by our emulation.
>> >
>> > If MPS always runs from the main thread, it doesn't (and cannot)
>> > suspend the thread.  Or maybe I misunderstand which thread do you mean
>> > here?
>> 
>> I may interpret "MPS runs in a thread" differently than you do.  Maybe I
>> should say a "thread is inside MPS" whenever a thread holds the arena
>> lock.  With this meaning, every thread can be inside MPS.
>
> Suspending a suspended thread on Windows doesn't cause any problems
> (unless you do that more than 127 times without resuming the thread),
> it just increments the thread's suspend count.  To resume, you need to
> call ResumeThread that many times.
>
> Does that answer your question?

Yes.

Helmut