when people say things like "ugh tokio just does async filesystem i/o in a blocking thread" as if the problem is tokio using a blocking thread for local filesystem i/o and not the initial proposal to use async for local filesystem i/o while expecting to get good performance. the filesystem is not like the network!
Post
the problem with blocking threads is that they're os threads and linux has cooties
anyway i figured out how to make this ring buffer interface with an os pipe
an actual good use case for vmsplice()
i am aware of the incredible safety concerns with it. using vmsplice() is one of the few times i have seen garbage in my bytes unintentionally. it has a very tricky post-condition in which i believe if you touch the memory range you sent (even if they're your bytes! that you allocated!) before the other end of the pipe reads out all the data you sent then you have to wipe the floors for linus torvalds for a millennia to make up for your misdeeds
@hipsterelectron Still dreaming of kvmfork() and the potential for distributed ultra-efficient micro-VMs. Really, kinda “ghost in the shell” if you think about it.