GNU bug report logs - #79333
31.0.50; Processes (still) aren't actually locked to threads

Previous Next

Full log

Message #11 received at 79333 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: dmitry <at> gutov.dev, 79333 <at> debbugs.gnu.org
Subject: Re: bug#79333: 31.0.50;
 Processes (still) aren't actually locked to threads
Date: Fri, 29 Aug 2025 10:35:15 +0300

> Cc: Eli Zaretskii <eliz <at> gnu.org>, Dmitry Gutov <dmitry <at> gutov.dev>
> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Thu, 28 Aug 2025 15:45:18 -0400
> 
> 
> 1. emacs -Q
> 2. Eval this:
> 
> (define-advice shell-command-sentinel (:before (process signal))
>   (message "process thread: %s, current thread: %s"
>            (process-thread process)
>            (current-thread)))
> (make-thread
>  (lambda ()
>    (async-shell-command "sleep 2")
>    ;; Do nothing.
>    (thread-join (make-thread (lambda () (while t (sit-for 1)))))))
> (sit-for 3)
> 
> 3. It hangs due to some thread bug, independent of the main bug I'm
>    reporting here.  Just hit C-g.  (Notably, it doesn't hang when run in
>    emacs --batch)
> 
> 4. Observe in *Messages* a message like this:
> 
> process thread: #<thread 0x3a25bf60>, current thread: #<thread 0x7f87c009e920>
> 
> The sentinel ran in a thread which is not process-thread.

I believe that's because of the way we process SIGCHLD on Posix
systems: we write to a special file descriptor to wake pselect.  That
file descriptor is used by all the subprocesses, so it cannot be made
thread-specific.  See child_signal_init and child_signal_notify.

Since this descriptor is shared by all the subprocesses, the sentinel
on Posix systems can run in the context of some random thread that
succeeds to grab the global lock after it returns from pselect.

Making sentinels run in the context of the thread that started the
process would require to redesign this part of Emacs.  Until then, we
will need to document this subtlety.

> So even after c93be71e45, processes aren't actually locked to threads.

Only the sentinel is not locked.

> (Once again, I think we should take the opportunity here to delete the
> code for locking processes to threads, since IMO it is not useful, and
> it is still broken)

I did explain why it is useful, and you haven't brought up any
arguments to the contrary.  And if "broken" means that the sentinel
can run in the context of a random thread, then how come you are
asking to leave it in this broken state?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.