GNU bug report logs - #13400
23.4; overlapping process filter calls

Previous Next

Full log

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 13400 <at> debbugs.gnu.org, hendrik <at> askra.de
Subject: Re: bug#13400: 23.4; overlapping process filter calls
Date: Fri, 09 Aug 2019 21:39:16 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> Hmm... I'm not sure I understand what would this mean in practice.
>> Suppose a process filter invokes some blocking API, which then calls
>> wait_reading_process_output, and 'pselect' tells us that same process
>> can be read from again.
>
> I think we shouldn't pass that process's handle to pselect.

That sounds like it would equivalent to setting the process' filter
function to t while running its body.  If you try that with the example
in the OP, you get a deadlock, because the subprocess' pipe becomes full
as Emacs stops reading it, and its input pipe becomes full so Emacs gets
stuck when trying to send data to it.

I thought you meant something more like my make-buffered-filter example,
where Emacs would still read from the process, but not call the filter
function with the new data until the current invocation ends (i.e.,
Emacs would just temporarily save the data).

Previous Next

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