GNU bug report logs - #51177
29.0.50; stop-process on pipes

Previous Next

Full log

View this message in rfc822 format

From: Helmut Eller <eller.helmut <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 51177 <at> debbugs.gnu.org
Subject: bug#51177: 29.0.50; stop-process on pipes
Date: Fri, 12 Nov 2021 09:28:49 +0100

On Fri, Nov 12 2021, Eli Zaretskii wrote:

>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Fri, 12 Nov 2021 07:30:45 +0100
>> Cc: 51177 <at> debbugs.gnu.org
>> 
>> As for the patch itself, I'd worry that a subtle change in semantics
>> here would break stuff (and this is an area that's full of notoriously
>> subtle things), but perhaps it's OK.  Anybody have an opinion here?

Ideally, there'd be test suite for those subtleties...

> First, the patch included an fprintf that should probably be removed.

Yes, of course.

> And second, I'd prefer to have a variable exposed to Lisp to control
> this behavior, so that if someone finds some strange consequences, we
> could ask them to flip the variable and see if the problem goes away.

Maybe that variable could be the filter itself.  We could delay closing
file descriptors only if the filter==t.  For the other values,
everything could stay as now.

> My main worry is what happens if we try reading from a pipe to a
> process that died, and so its end of the pipe could be closed.  Was
> this patch tested when process-connection-type is nil?

Just tested it.  Works.

I do wonder why the part of the code with the comment "If process is
still active, read any output that remains" is not executed for the
deleting_process.  It seems to me that this creates the possibility (with
very low probability) that we forget to read the last chunk of output in
the usual case where filter ≠ t.

Helmut

Previous Next

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