Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I find this surprising, given that my initial response to reading the iouring design was:

1. This is pretty clean and straightforward. 2. This is obviously what we need to decouple a bunch of things without the previous downsides.

What has made it so hard to integrate it into common language runtimes? Do you have examples of where there's been an irreconcilable "impedance mismatch"?



https://github.com/tailscale/tailscale/pull/2370 was a practical drive toward this, will not proceed on this path.

much more approachable, boats has written about challenges integrating in rust: https://without.boats/tags/io-uring/

in the most general form: you need a fairly "loose" memory model to integrate the "best" (performance wise) parts, and the "best" (ease of use/forward looking safety) way to integrate requires C library linkage. This is troublesome in most GC languages, and many managed runtimes. There's also the issue that uring being non-portable means that the things it suggests you must do (such as say pinning a buffer pool and making APIs like read not immediate caller allocates) requires a substantially separate API for this platform than for others, or at least substantial reworks over all the existing POSIX modeled APIs - thus back to what I said originally, we need a replacement for POSIX & BSD here, broadly applied.


I can see how a zero-copy API would be hard to implement on some languages, but you could still implement something on top of io_uring with posix buffer copy semantics , while using batching to decrease syscall overhead.

Zero-copy APIs will necessarily be tricky to implement and use, especially on memory safe languages.


I think most GC languages support native/pinned me(at least Java and C# do memory to support talking to kernel or native libraries. The APIs are even quite nice.


Java's off-heap memory and memory segment API is quite dreadful and on the slower side. C# otoh gives you easy and cheap object pinning, malloc/free and stack-allocated buffers.


I read the oldest of those blog posts the closest.

Seems like the author points out two things:

1. The lack of rust futures supporting manual cancellation. That doesn't seem like an inevitable choice by rust.

2. Sharing buffers with kernel mode. This is probably a bigger topic.


Rust's async model can support io-uring fine, it just has to be a different API based on ownership instead of references. (That's the conclusion of my posts you link to.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: