bug#44007: 26.3; Strange shell mode performance

[Eli Zaretskii <eliz@gnu.org>]

> From: Herman, Géza <geza.herman@gmail.com>
> Cc: Herman Géza <geza.herman@gmail.com>,
>  44007@debbugs.gnu.org
> Date: Mon, 06 Nov 2023 16:00:00 +0100
> 
> 
> 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.

That doesn't matter here.  The problem is not with blocking in 'read',
the problem is with calling one 'read' after another without letting
Emacs process the foreground input events.

> But even if it's not, how does Emacs determine nbyte parameter?

It's a parameter, which is exposed to Lisp, so can be controlled, but
otherwise is not based on anything.

> Because I suppose it should be at most as large as the available
> data in the fd.

Emacs doesn't know how much is available, it only knows that some
positive amount is available.

> If not, then emacs_intr_read already has the chance of blocking
> anyway without the loop.

Again, blocking is not the issue, see above.