bug#44007: 26.3; Strange shell mode performance

[Herman@debbugs.gnu.org, Géza <geza.herman@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

> I believe reading again immediately could make Emacs 
> unresponsive for
> prolonged periods of time.  We are talking about reading 
> sub-process
> output asynchronously, which means we must not read in a tight 
> loop,
> because that would have the same effect as calling a subprocess
> synchronously and waiting for it to finish.
>
> Even in this particular scenario, the user should be able to 
> switch to
> another buffer and issue commands, while Emacs is reading from 
> the
> shell or some program invoked from the shell.

I thought that the fd is nonblocking here. But even if it's not, 
how does Emacs determine nbyte parameter? Because I suppose it 
should be at most as large as the available data in the fd. If 
not, then emacs_intr_read already has the chance of blocking 
anyway without the loop.

Also, I have the loop in place for years, and didn't notice any 
problems.