Re: performance of shell read loops

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Mar 07, 2016 at 04:09:06PM +0700, Robert Elz wrote:
> 
> Then I ktrace'd it, and of course, the "read" builtin command is reading
> one character at a time.   If you think about it just a litte, you will
> see that it must work that way (it is only permitted to take one line of
> data from stdin, whatever follows the \n must be still available there for
> the next command, whatever it is.)

It could do better if the input was seekable, but the shell is much
more likely to be reading from a pipe.

Clearly pipes could have had a 'line mode' - but they don't.

An interesting option would be getting recv(..., MSG_PEEK)
to work on pipes!
Actually since read() is just recv(fd, buf, len, 0) the entire
kernel could be converted to to support recv() instead of read().
That would allow a MSG_LINE flag to be implemented that terminated
on a '\n' character.

	David

-- 
David Laight: david%l8s.co.uk@localhost