[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: performance of shell read loops
Date: Sat, 12 Mar 2016 14:50:59 +0100
From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
| I'm not sure. A lot of shell processing also happens on real files.
There are three cases that could work to improve this - when input is
seekable, when it is a tty, and when analysis of the command sequence
shows nothing else can possibly read the stdin that is being read by read
(which would have handled DHolland's test case OK).
The former two tests are fairly easy, and could be done, though it would need
a little care to calculate the seek position for the seekable input case, and
make sure to always seek when required.
A "good enough" test for the third could, I think, be done by (assuming the
read command is in a while/until loop - if not we don't care that it does
byte at a time reads, and for loops always might exit prematurely) checking
that the loop only exits (only can exit - signals aside, they would always
leave an undefined state, so don't matter) when read "fails" (ether by
writing the loop as
while read whatever
done < somewhere
(or similar using piped input) or writing it as
while : # or true
read whatever || break ; # or return or exit
and that there are no non-builtin commands in the loop that don't have
their own stdin redirected, and no other ways to escape the loop (no
break or return triggered by any other conditio) - unless the stdin is
open only for this loop (as in the "done < somewhere" case above)
builtin commands could cooperate with whatever buffering read was doing,
so they wouldn't be an issue (not that there are any that read stdin that
I recall, other than read).
I have been idly considering whether those tests would be reasonable to
| 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.
I was too - but I suspect that the only users that matter would want \n
as the terminator (or EOF of course) - other stuff (vi input mode that
can end on ESC) don't do enough input for it to be worth the bother. So
I suspect that just line mode buffering (like ttys do, and like is available
on output via stdio) would probably be enough for 90% of uses, or more.
More complexity just makes it harder to use, and more likely to be full of
bugs. "Line mode input" could be a simple fcntl flag.
Main Index |
Thread Index |