On Mon, 22 Apr 2024, Martin D Kealey wrote:
On Mon, 22 Apr 2024, 09:17 Carl Edquist, <edqu...@cs.wisc.edu> wrote:
[…] I was saying the shell is crippled when limited to builtins; eg, a
read/printf loop compared to simply running cat.
I would hope that mapfile/readarray could do better, since it's not
obligated to leave anything in the input stream.
That is an interesting thought, although mapfile seems to read a byte at a
time also.
[I'm not suggesting this should be changed though. And frankly I have no
strong desire for a faster 'read' builtin in the shell, either. A byte at
a time is relatively slow, but that's generally fine in most limited
contexts where it's actually needed.]
But yeah currently a pipe with a series of records and multiple
cooperating/competing readers perhaps only works if the records have a
fixed size. A new readd[elim] system call like you're talking about
would allow safely reading a single variable-length record at a time.
There are other options, such as length-prefixed records, or tagged
(typed) records, but of course those aren't POSIX text files.
That'd work for "cooperating" readers (as you put it) where they are not
attempting to read at the same time. Though reading a single byte at a
time also works in that case.
My thought is that (performance considerations aside), the real functional
improvement with a new "readd" call would be with _competing_ readers
(more than one read call waiting on the same pipe at the same time).
In that case a length-prefixed or type-tagged record wouldn't seem to work
with the regular read(2), because a single reader would not be able to
read the length/type _and_ the corresponding record together. You can't
work around this by reading a byte at a time either. That's why I said it
would only seem to work (with read(2)) if the records have a fixed size.
(In order to grab a whole record atomically.)
But a new "readd" call would allow multiple competing readers to read,
say, a stream of filenames from a pipe, without having to pad each one to
PATH_MAX bytes.
It seems that if there is only one reader at a given time though
("cooperating"), then it's just a matter of performance between
read(2)'ing one byte at a time vs using a new readd call.
...
I'm not trying to advocate for or against you contacting the kernel folks
with your idea; it just seems to me that the scenario with multiple
competing readers might be the strongest argument for it.
Carl
