Live data from Hacker News

A programmer-friendly I/O abstraction over io_uring and kqueue

tigerbeetle.com

31–34 of 34 posts

Re: A programmer-friendly I/O abstraction over io_uring and kqueue

#31
post #26

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 ?

That's the one!

Re: A programmer-friendly I/O abstraction over io_uring and kqueue

#32
post #16

"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...

Just curious, what's the use-case for this?

Re: A programmer-friendly I/O abstraction over io_uring and kqueue

#33
post #16

Earlier 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?

Any library that is supposed to leave a socket or other handle in the same state in which it got it.

Re: A programmer-friendly I/O abstraction over io_uring and kqueue

#34
post #33

Earlier 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.

Yeah I suppose. Not used to such libraries, the ones I've used either control the creation of the handle or take ownership.
Post reply on HN