Re:QUIC Is Not Quick Enough over Fast Internet
by gpderetta on Monday September 09, 2024 @07:59AM
(#41487715)
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.
Re:QUIC Is Not Quick Enough over Fast Internet
by gmokki on Monday September 09, 2024 @11:31AM
(#41489524)
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.
Re:QUIC Is Not Quick Enough over Fast Internet
by neonsunset on Monday September 09, 2024 @11:48AM
(#41489726)
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.
Re:QUIC Is Not Quick Enough over Fast Internet
by asveikau on Monday September 09, 2024 @11:28AM
(#41489485)
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.
Re:QUIC Is Not Quick Enough over Fast Internet
by withoutboats3 on Monday September 09, 2024 @01:42PM
(#41491189)
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.)
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.