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

[Matthias Dahl <ml_emacs-lists@binary-island.eu>]

Hello Paul...

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.

Thus, that should not happen. And there is actually nothing Emacs can do
about it form its side. This is solely the responsibility of package
authors and so forth to make sure things like that do not happen through
the usual mechanics and techniques.

And doing the same from a filter... well... everything stated above is
true here as well.

The current situation is without a doubt a bug -- Emacs should detect
that data was read and processed and not hang indefinitely. That we can
agree on, I hope. :-)

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.

Again, I do not see the problem with my solution. We cannot and should
not account for bugs in 3rd party package implementations like the one
state earlier above.

If I'm wrong here or missing something, please don't hesitate to correct
me. Right now, at least, I am not seeing any problems.

Have a nice weekend,
Matthias

-- 
Dipl.-Inf. (FH) Matthias Dahl | Software Engineer | binary-island.eu