Non-blocking buffered file read operations

Posted Oct 1, 2014 11:25 UTC (Wed) by nix (subscriber, #2304)
Parent article: Non-blocking buffered file read operations

I'm wondering why there's this obsession with adding flags for every new feature. System calls are not a fundamentally limited resource: we're not going to run out.

You want a flag if it is likely that a program will want to call the function both with and without the flag from the same locus: changing the flags programmatically is a tiny bit easier than changing what function you're calling. But it will be rare to want to sometimes synchronously and sometimes asynchronously read() from the same read()-calling locus. And for this we're getting system calls with the viciously ugly names of '*v2()' and a bunch of flags? (This is particularly true given that the iovec-based interface proposed, while the only possible one, is clumsy enough that nobody will use this call unless they want asychronous I/O. So we have a flag here that will never be left out! Not until more flags are proposed, anyway.)

Tell me, which is easier to read?

reada(foo, bar, baz);
readv2(foo, bar, baz, RWF_NONBLOCK);

I'd say it's the former. It's not so SHOUTY, and the name is a bit clearer. (Though there's not much in it.)

Non-blocking buffered file read operations

Posted Oct 2, 2014 9:34 UTC (Thu) by ssokolow (guest, #94568) [Link] (1 responses)

Correct me if I'm wrong, but I seem to remember an LWN article from a few years ago where room for new system calls being a limited resource WAS listed as a concern because the kernel ABI distinguished syscalls by integer identifiers rather than character strings for performance reasons.

Non-blocking buffered file read operations

Posted Oct 7, 2014 17:01 UTC (Tue) by nix (subscriber, #2304) [Link]

What, so we can only have billions of them? That's not limited enough to provide a reason to not make something a system call. :)

(More relevant is that you need to wait until support percolates into glibc to use a system call, or have applications hardwire the call themselves during the transition period -- but the same applies to adding new flag bits, since you need to wait for their symbolic constants to hit glibc, or have applications hardwire the call themselves.)