> Along with this, you need async I/O. This is primarily for log files and managed files. When you do a write, you get two callbacks, one when the buffer has been copied, and one when the data has been committed to permanent storage and will survive a crash.
This is what you want if you need to communicate the durability guarantee to the outside world, but if you’re just trying to enforce some consistency guarantees for internal purposes (e.g. transaction journal write goes out before data write), callbacks impose an unnecessary CPU-disk-CPU roundtrip. That’s what Featherstitch[1] was trying to avoid. Or is that not worth it?
More generally, how does this compare to other throughput-oriented queue-adjacent things, such as GPU commands buffers and fences, or Linux io_uring and Windows RIO? (A comparison to NIC queues is probably less interesting because NICs don’t reorder things—or do they? What about radios?) Do all of these need to be separate mechanisms?
Sudden thought: Featherstitch is to completion callbacks as promise pipelining[2] is to traditional RPC.
This is what you want if you need to communicate the durability guarantee to the outside world, but if you’re just trying to enforce some consistency guarantees for internal purposes (e.g. transaction journal write goes out before data write), callbacks impose an unnecessary CPU-disk-CPU roundtrip. That’s what Featherstitch[1] was trying to avoid. Or is that not worth it?
More generally, how does this compare to other throughput-oriented queue-adjacent things, such as GPU commands buffers and fences, or Linux io_uring and Windows RIO? (A comparison to NIC queues is probably less interesting because NICs don’t reorder things—or do they? What about radios?) Do all of these need to be separate mechanisms?
Sudden thought: Featherstitch is to completion callbacks as promise pipelining[2] is to traditional RPC.
[1] https://lwn.net/Articles/354861/
[2] https://capnproto.org/rpc.html