I just watched your talk at the CMU database talks. Just wanted to say I really appreciate reading/hearing about your approach! TB is a super interesting system, I hope I get to properly use it someday.
Which talk is this? This one: https://www.youtube.com/watch?v=FyGukn77gqA ?
A programmer-friendly I/O abstraction over io_uring and kqueue
31–34 of 34 posts
Re: A programmer-friendly I/O abstraction over io_uring and kqueue
#32"The good news is that Windows also has a completion based system similar to io_uring but without batching, called IOCP" fwiw IOCP in NT predates the similar mechanisms in Linux by at least a decade (and the VMS QIO scheme upon which it was in turn based is even older). As I understand it the reason Unix(1) (and then Linux) did not have efficient network I/O kernel interfaces until relatively recently was due to fear…
IOCP was missing a rather obvious feature until recently: disassociating a handle from an IOCP: https://stackoverflow.com/questions/30688028/un-associate-so...
Re: A programmer-friendly I/O abstraction over io_uring and kqueue
#33Earlier quoted context omitted.
IOCP was missing a rather obvious feature until recently: disassociating a handle from an IOCP: https://stackoverflow.com/questions/30688028/un-associate-so...
Just curious, what's the use-case for this?
Re: A programmer-friendly I/O abstraction over io_uring and kqueue
#34Earlier quoted context omitted.
Just curious, what's the use-case for this?
Any library that is supposed to leave a socket or other handle in the same state in which it got it.