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

Previous Next

Full log

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

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 79333 <at> debbugs.gnu.org
Subject: Re: bug#79333: 31.0.50; Processes (still) aren't actually locked to
 threads
Date: Mon, 1 Sep 2025 04:24:27 +0300

On 29/08/2025 19:06, Spencer Baugh wrote:
>      > If the program was instead something like:
>      >
>      > (let ((proc (make-process ...)))
>      >   (sit-for 1)
>      >   (accept-process-output proc))
>      >
>      > then the (accept-process-output proc) might block because the sit-for
>      > can thread switch.  But this program is already buggy, since sit-for
>      > runs wait_reading_process_output which could read the output from
>     PROC.
> 
>     A program can easily call sit-for indirectly, because sit-for is
>     called all over the place in Emacs.
> 
> 
> That's my point.  This second example program is buggy whether threads 
> are used or not.

I wonder if we would consider comint-proc-query already problematic in 
this regard.

It does:

      (comint-send-string proc str) ; send the query
      (accept-process-output proc)  ; wait for some output

and comint-send-string -> process-send-string -> send_process, which has 
a 'wait_reading_process_output' call inside.

Is it at least theoretically possible that the latter call consumes the 
output from the process, making the subsequent accept-process-output 
call in the function hang?

Previous Next

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