GNU bug report logs -
#79333
31.0.50; Processes (still) aren't actually locked to threads
Previous Next
Full log
Message #38 received at 79333 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 1 Sep 2025 04:24:27 +0300
> Cc: 79333 <at> debbugs.gnu.org
> From: Dmitry Gutov <dmitry <at> gutov.dev>
>
> 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.
This bug report was last modified 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.