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
Replies:
7
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 I know `mmap` requires page alignment for perfectly good reasons that can't be changed realistically, but if one could `mmap` arbitrary byte ranges it would solve *so* many problems with zero copy IPC and syscalls.
@heptapodEnthusiast this could be a fun game show idea. give os devs a proposal that could never work but would be cool as shit and give them 30 minutes to brainstorm an implementation
@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.
