5 ms·

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 cho

by mavam 7y ago

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?

earenndil 7y ago
Once freebsd's linux implementation supports io_uring, you'll be able to use that there too. Nothing for macos, though, I'm afraid.
- yxhuvud 7y ago
  Is there plans to support it?
  - trasz 7y ago
    Not until it becomes actually used by real-world code, I suppose.
- cpach 7y ago
  I’m afraid I don’t follow. What do you mean by “freebsd’s linux implementation”?
  - jacobush 7y ago
    FreeBSD can run linux binaries: https://www.freebsd.org/doc/handbook/linuxemu.html 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.
    - cesarb 7y ago
      > 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.
    - trasz 7y ago
      Better way would be to provide those as native syscalls and then provide Linuxulator wrappers over those.
blattimwind 7y ago
> 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?

by mavam 7y ago

earenndil 7y ago

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

yxhuvud 7y ago
Is there plans to support it?
- trasz 7y ago
  Not until it becomes actually used by real-world code, I suppose.
cpach 7y ago
I’m afraid I don’t follow. What do you mean by “freebsd’s linux implementation”?
- jacobush 7y ago
  FreeBSD can run linux binaries: https://www.freebsd.org/doc/handbook/linuxemu.html 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.
  - cesarb 7y ago
    > 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.
  - trasz 7y ago
    Better way would be to provide those as native syscalls and then provide Linuxulator wrappers over those.

blattimwind 7y ago

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