Re: performance of shell read loops

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Sat, Mar 12, 2016 at 12:08:10PM +0000, David Laight wrote:
> 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.

I'm not sure. A lot of shell processing also happens on real files. I
asked Steve Bourne about this case today and he was a bit surprised that
it hasn't been fixed yet :)

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

TTYs do, don't they?

> 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.

Actually I was wondering if there aren't more use cases for a "read
until you find the following sequence" system call or just something
specifiying a (simple) regular expression. Even a BPF program would be
an interesting option.

Joerg