bug#48118: 27.1; 28; Only first process receives output with multiple running processes

[Eli Zaretskii <eliz@gnu.org>]

> Cc: 48118@debbugs.gnu.org
> From: Daniel Mendler <mail@daniel-mendler.de>
> Date: Fri, 30 Apr 2021 17:39:35 +0200
> 
> >> Which scenarios break?
> > 
> > For example, if the filter function call accept-process-output.  Or
> > does anything else that changes output from which processes is or
> > isn't available.
> 
> Does this necessarily prevent scheduling? I interpret
> `accept-process-output` as a function which prioritizes a process, but I
> am unsure if this makes it impossible to implement additional scheduling.

A call to accept-process-output prioritizes a process only if it
explicitly requests output from that single process.  Which is not
necessarily true in all cases.

> > What does this mean, exactly?  Which quantity should be doled in a
> > round-robin fashion? bytes read from the processes? something else?
> > 
> > If the bytes read, then how do you suggest to handle two processes
> > which produce output at very different rates?
> 
> For example bytes read or time spent to handle a process (time spent in
> the filter function?).

Bytes read has a problem when processes produce output a very
different rates.  Time spent to handle may (and usually does) mean the
filter function does something expensive, it doesn't necessarily tell
anything about the output from the subprocess.

> When I stumbled over this issue, it astonished me that Emacs
> does not seem to do any scheduling at all and handles only a single
> process.

If you read the code, you will see this isn't what happens.  What
happens is that Emacs reads a chunk of output from the first process
it sees ready, then it goes back and re-checks which processes are
ready -- and in your scenario I think it again sees that the first
process is ready.

> What is the reason for the current behavior? Is it predictability? If I
> understand correctly, Emacs always reads from the first process. If data
> arrives, Emacs does not read from the second processes at all. Only if
> no data is available from the first process, the second process is
> handled. Is it like this?

In your scenario, yes.  It depends on how large is the output produced
by a process in one go.

I suggest to read the code of wait_reading_process_output, it has some
non-trivial logic in this department.