Re: SIGPROF + SIGCHLD and igc

[Pip Cet via "Emacs development discussions." <emacs-devel@gnu.org>]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Sat, 28 Dec 2024 20:43:18 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, gerd.moellmann@gmail.com, ofv@wanadoo.es, emacs-devel@gnu.org, acorallo@gnu.org
>>
>> "Helmut Eller" <eller.helmut@gmail.com> writes:
>>
>> > On Sat, Dec 28 2024, Pip Cet wrote:
>> >
>> >>> I think I see what you mean.  I imagine the profiler thread to be a loop
>> >>> like
>> >>>
>> >>>   while (true) {
>> >>>      sleep (<x-seconds>)
>> >>>      ArenaEnter (<arena>)
>> >>>        pthread_kill (SIGPROF, <main-thread>)
>> >>>        wait (<pipe>)
>> >>>      ArenaLeave (<arena>)
>> >>>   }
>> >>
>> >> I'm not really following.  Did you mean to include a call to a "clear
>> >> all memory barriers" function after the ArenaEnter call?  If not, the
>> >> SIGPROF handler (and all handlers interrupting the SIGPROF handler which
>> >> aren't being delayed) would not be able to access MPS memory, which I
>> >> thought was the goal.
>> >
>> > In my mind it works like this: when the SIGPROF handler tries to access
>> > MPS memory, the SIGSEGV handler kicks in as it usually would in a
>> > non-signal handler context.  This should work because at the beginning
>> > of the SIGPROF handler we guarantee that MPS doesn't hold the arena
>> > lock.
>>
>> Sorry, still not following.  The SIGPROF-sending thread holds the arena
>> lock.  So we can't take it in the SIGSEGV handler.  It's still a
>> deadlock, right?
>
> But the SIGPROF handler doesn't take the arena lock, it starts by
> writing to the pipe, which then causes the SIGPROF-sending thread to
> release the lock, thus letting the SIGPROF handler touch memory which
> could trigger MPS into taking the lock.

Thanks, I got the idea now!

Yes, that would work, assuming SIGPROF is never blocked, and that no
signal interrupting the SIGPROF handler attempts to take the arena lock.
(Also, we assume the SIGPROF handler has finished by the time the next
SIGPROF is sent.  I think this assumption is fixable, though, and we'd
need to fix it for other signals).

Pip