On Sun, 21 Apr 2024, 10:13 Carl Edquist, <edqu...@cs.wisc.edu> wrote:
> On Thu, 18 Apr 2024, Martin D Kealey wrote: > > Has anyone tried asking any of the kernel teams (Linux, BSD, or other) > > to add a new system call such as readln() or readd()? > > You mean, specifically in order to implement a slightly-more-efficient > 'read' builtin in the shell? > The read built-in in the shell is only one case that would benefit from such a syscall. The purpose would be to allow multiple processes to read in turn from a consumable (or otherwise non seekable) input stream. In this context doing a large block read() is exactly what we DON'T want to do, so we also can't use a library function such as getline() that is built on top of such a read(). By way of example, another use would be the "head" utility, which by using such a syscall could consume only the bytes it outputs, leaving all other bytes still in the input stream. This would be an improvement over the current situation. Basically any time you have cooperating processes reading delimited input, this would be an improvement. > I envisage this working like stty cooked mode works on a tty, > … > One downside is you'd end up with a system call for each token That's not how stty cooked mode normally works. The typical use case is line-at-a-time, so this would reduce the number of system calls by about 90% on a typical text input stream, more if there are few or no blank lines. However I would not hard code "newline" into the kernel, but rather allow the user code to nominate a list of delimiters. -Martin