Hacker News Reader

Comment by mavam | Hacker News Reader

For users who need macOS and FreeBSD (kqueue) support as well, is there any unified standard for async I/O that covers both file and network? Or is the only choice to go with a library like libuv, which will always pick the optimal native implementation under the hood?

View on HN

Once freebsd's linux implementation supports io_uring, you'll be able to use that there too. Nothing for macos, though, I'm afraid.

I’m afraid I don’t follow. What do you mean by “freebsd’s linux implementation”?

FreeBSD can run linux binaries:

https://www.freebsd.org/doc/handbook/linuxemu.html

I wonder though... wouldn't a safe first way of implementing these new syscalls be to make them actually synchronous?

That way you'd be able to run these Linux binaries but without any of the performance benefits.

> I wonder though... wouldn't a safe first way of implementing these new syscalls be to make them actually synchronous?

No, because it visibly changes the semantics. Consider for instance IORING_OP_ACCEPT; if you make it synchronous, and nothing connects to your program, it would wait forever, instead of returning immediately and allowing the program to continue. The file-related opcodes are safer (when used with actual files, instead of network sockets), but still would behave differently for instance with a hanging NFS mount.

Better way would be to provide those as native syscalls and then provide Linuxulator wrappers over those.

Is there plans to support it?

Not until it becomes actually used by real-world code, I suppose.

> Or is the only choice to go with a library like libuv, which will always pick the optimal native implementation under the hood?

You mean thread-pools for file I/O?

Reply on news.ycombinator.com