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.