On Sat, Apr 27, 2024 at 1:01 PM Carl Edquist <edqu...@cs.wisc.edu> wrote:
>
> On Mon, 22 Apr 2024, Martin D Kealey wrote:
>
> > On Mon, 22 Apr 2024, 09:17 Carl Edquist, <edqu...@cs.wisc.edu> wrote:
> >
> >> 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.
Where it's available, you'd probably want to do this with a POSIX
message queue with all the messages sent with the same priority.
If you really want a bash competing-process job-server arrangement by
passing messages through a single pipe, you might be able to use
flock(1) to ensure that only one process is allowed to read from the
pipe at a time.
If you take out this use case, a potential readd[elim] call does sound
like it's kind of just there to have a more efficient read command in
the shell.
