Re: wait_reading_process_ouput hangs in certain cases (w/ patches)

[Eli Zaretskii]

> Cc: address@hidden
> From: Matthias Dahl <address@hidden>
> Date: Sat, 18 Nov 2017 15:24:26 +0100
> 
> On 16/11/17 17:46, Paul Eggert wrote:
> 
> > Sure, but how do we know that the data read while running timers and
> > filters was being read on behalf of our caller? Perhaps a timer or
> > filter fired off some Elisp function that decided to read data for its
> > own purposes, unrelated to our caller. We wouldn't want to count the
> > data read by that function as being data of interest to our caller.
> 
> I had considered that when I debugged the bug but think about it for a
> moment. If you treat the process as a shared resource, it is your sole
> responsibility to take care of proper management and synchronization of
> the process as well.
> 
> If a wait_... is in progress for process A which is the response to some
> interaction A* (w/ filter F1), then if the timers get processed during
> our wait and end up with another interaction B* (w/ filter F2) to
> process A that will cause havoc either way. They will probably read the
> data that was destined for filter F1 or things get messed up even more
> horribly.

I think the normal situation is where each process has only one
filter, and therefore even if the output of the process was read by
some unrelated call to wait_reading_process_output, that output was
processed by the correct filter.

IOW, there should be no problems with the actual processing of the
process output, the problem is with the caller of
accept-process-output etc., which must receive an indication that some
output was received and processed.  And that's what the proposed
change is trying to solve -- to prevent that indication from being
lost due to recursive calls to wait_reading_process_output.

> We could, by the way, avoid this whole problem and dilemma if we shift
> the processing of timers to _AFTER_ we are finished with everything. But
> this brings in new problems, like if we have to wait too long for the
> data to become available, timers would get delayed quite a bit. And they
> would only fire once, no matter how much time has passed. So this is not
> ideal as well.

No, this will introduce much worse problems.