bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Examples of concurrent coproc usage?


From: Carl Edquist
Subject: Re: Examples of concurrent coproc usage?
Date: Sat, 27 Apr 2024 12:03:11 -0500 (CDT)

On Mon, 22 Apr 2024, Martin D Kealey wrote:

On Mon, 22 Apr 2024, 09:17 Carl Edquist, <edquist@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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]