Subject: bug#79333: 31.0.50; Processes (still) aren't actually locked to threads

From: Eli Zaretskii <[email-masked]>
Date: Mon, 01 Sep 2025 17:59:06 +0300

> Date: Mon, 1 Sep 2025 04:24:27 +0300
> Cc: [email-masked]
> From: Dmitry Gutov <[email-masked]>
> 
> 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.

Why do you think this could be problematic?

> 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?

It shouldn't.  send_process only calls wait_reading_process_output if
it cannot write the whole string in one go, AFAIR, in which case the
last part of the process's output should still be available to
accept-process-output call.