Note on “Reforming Unix”

[alexshpilkin]

One approach that can express weaker ordering constraints than fsync() and barriers is Featherstitch, where you more or less specify the partial order directly. Notably, the original paper implements soft updates on top of it. Unfortunately, it looks like avoiding the approximate heuristic used there is a nontrivial graph-theory problem.

I’m itching a bit to think of the partial order as promise pipelining. That is, even (e.g.) write() returns a promise (of a unit type?) that’s broken on error, and all I/O ops also accept such promises so failures propagate automatically. Now all you need to express a partial order is an all() operation that fails if any of its argument promises fail, and otherwise succeeds with the unit value. (The actual E language described on the linked website guarantees fail-stop FIFO semantics for messages sent to a single reference, whereas for I/O we essentially only want the dependency order. I’m not sure how I feel about this.)

Would also be interesting to know if throughput-oriented hardware that speaks command queues (GPUs, NVMe drives) exposes anything more advanced than barriers. I’ve never heard of anything like that, but then I’m not a hardware person.

Finally, the statement that file descriptors are good may require a bit of qualification—opaque unforgeable handles are good, but the wisdom of the dense small-integer namespace is questionable. (I seem to remember it being a bit of a problem for io_uring, even, though I don’t have the link.) The two alternatives are, of course, having the system or the user maintain a sparse one. The former option has the problem that well-known fd numbers in the fashion of stdin/stdout/stderr are no longer possible; the latter has the problem that the first thing a usable ABI needs is to introduce a shared namespace manager, thus essentially turning this option back into one of the others.