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

Previous Next

Full log

View this message in rfc822 format

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: bug#79333: 31.0.50; Processes (still) aren't actually locked to threads
Date: Fri, 29 Aug 2025 16:55:19 +0300

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Cc: dmitry <at> gutov.dev,  79333 <at> debbugs.gnu.org
> Date: Fri, 29 Aug 2025 09:29:37 -0400
> 
> > I don't understand why one thread starts a process, then another
> > thread waits for its output, and the program which arranges for that
> > doesn't unlock the process so the other thread could do its job.
> 
> Yes, that's the bug.
> 
> It is not intentional that the process is started in a thread.  That is
> what causes the bug.
> 
> > This is what set-process-thread is
> > for, and in this (IMO rather unusual) arrangement, calling it with a
> > nil THREAD argument is exactly what should be done.
> 
> The point is that these are two independent pieces of code, written by
> different authors.
> 
> If they just happen to interleave in this way, then the process is
> *accidentally, unintentionally* started in a thread.
> 
> How would the author of snippet 1 know to call set-process-thread in
> this case?

If you are saying that two arbitrary independently-written pieces of
code can get in trouble if they are lumped together to run by the same
Lisp program in two separate threads, then I agree.

However, having a function that starts a process, but doesn't process
its output, and another function that doesn't start any processes, but
does accept output from subprocesses, is an unusual thing to do.  This
could happen as a deliberate design of a program, but then we are not
talking about two snippets oblivious to one another, because the
person who brings them together like that in the same program does
that deliberately, and should understand that for it to work, the
process should be either unlocked or locked to the thread which wants
to read and process its output.

IOW, when making such programs where threads are not independent calls
for some adjustments in the code of each thread.

What I have in mind is a different case, which I think is much more
common, at least at this stage of using Lisp thread in Emacs.  It's a
case where one takes a single-threaded Lisp program, and runs it from
a separate thread so as to avoid blocking the Emacs's main thread.  In
that case, the same thread will both start the process and expect to
be able to process its output (because that's how single-threaded Lisp
programs work), and therefore having the process locked by default
lets such code work as expected when it is run from a thread.
Especially if you take several such programs, each with its own
subprocess, and let them all run from several different threads at the
same time.

Previous Next

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