Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Io_uring, kTLS and Rust for zero syscall HTTPS server

blog.habets.se

Post reply on HN
Print view View original

31–40 of 173 posts

Re: Io_uring, kTLS and Rust for zero syscall HTTPS server

#31

Post by josephg »

avar wrote: post #26
kev009 wrote: post #12

Earlier quoted context omitted.

It wasn't just CGI, every HTTP session was commonly a forked copy of the entire server in the CERN and Apache lineage! Apache gradually had better answers, but their API with common addons made it a bit difficult to transition so webservers like nginx took off which are built closer to the architecture in the article with event driven I/O from the beginning.

every HTTP session was commonly a forked copy of the entire server in the CERN and Apache lineage! And there's nothing wrong with that for application workers. On *nix systems fork() is very fast, you can fork "the entire server" and the kernel will only COW your memory. As nginx etc. showed you can get better raw file serving performance with other models, but it's still a legitimate technique for application logic…

So long as you have something like nginx in front of your server. Otherwise your whole site can be taken down by a slowloris attack over a 33.6k modem.

Re: Io_uring, kTLS and Rust for zero syscall HTTPS server

#32

Post by pornel »

jcranmer wrote: post #14
Seattle3503 wrote: post #9

> For example when submitting a write operation, the memory location of those bytes must not be deallocated or overwritten. > The io-uring crate doesn’t help much with this. The API doesn’t allow the borrow checker to protect you at compile time, and I don’t see it doing any runtime checks either. I've seen comments like this before[1], and I get the impression that building a a safe async Rust library around io_urin…

There is, I think, an ownership model that Rust's borrow checker very poorly supports, and for lack of a better name, I've called it hot potato ownership. The basic idea is that you have a buffer which you can give out as ownership in the expectation that the person you gave it to will (eventually) give it back to you. It's a sort of non-lexical borrowing problem, and I very quickly discovered when trying to implemen…

This can be done with exclusively owned objects. That's how io_uring abstractions work in Rust – you give your (heap allocated) buffer to a buffer pool, and get it back when the operation is done.

&mut references are exclusive and non-copyable, so the hot potato approach can even be used within their scope.

But the problem in Rust is that threads can unwind/exit at any time, invalidating buffers living on the stack, and io_uring may use the buffer for longer than the thread lives.

The borrow checker only checks what code is doing, but doesn't have power to alter runtime behavior (it's not a GC after all), so it only can prevent io_uring abstractions from getting any on-stack buffers, but has no power to prevent threads from unwinding to make on-stack buffer safe instead.

Re: Io_uring, kTLS and Rust for zero syscall HTTPS server

#34

Post by zozbot234 »

rfoo wrote: post #27
tayo42 wrote: post #18

Earlier quoted context omitted.

Refcel didn't work? Or rc?

Slapping Rc over something that could be clearly uniquely owned is a sign of very poorly designed lifetime rules / system. And yes, for now async Rust is full of unnecessary Arc and is very poorly made.

If the thread can be dropped while the buffer is "owned" by the kernel io-uring facilities (to be given back when the operation completes) that's not "unique" ownership. The existing Rc/Arc may be overkill for that case, but something very much like it will still be needed.

Re: Io_uring, kTLS and Rust for zero syscall HTTPS server

#35

Post by IshKebab »

stouset wrote: post #16
jcranmer wrote: post #14

Earlier quoted context omitted.

There is, I think, an ownership model that Rust's borrow checker very poorly supports, and for lack of a better name, I've called it hot potato ownership. The basic idea is that you have a buffer which you can give out as ownership in the expectation that the person you gave it to will (eventually) give it back to you. It's a sort of non-lexical borrowing problem, and I very quickly discovered when trying to implemen…

Maybe I’m misunderstanding, but why is that not possible with a Fn(_: T) -> T

How is that different to

  Fn(_: &mut T)

?

Re: Io_uring, kTLS and Rust for zero syscall HTTPS server

#36

Post by thomashabets2 »

mgaunard wrote: post #22

"zero syscall" > In order to avoid busy looping, both the kernel and the web server will only busy-loop checking the queue for a little bit (configurable, but think milliseconds), and if there’s nothing new, the web server will do a syscall to “go to sleep” until something gets added to the queue.

Under load it's zero syscall (barring any rare allocations inside rustls for the handshake. I can't guarantee that it never does).

Without load the overhead of calling (effectively) sleep() is, while technically true, not relevant.

But sure, you can tweak the busyloop timers and burn 100% CPU on kernel and user side indefinitely if you want to avoid that sleep-when-idle syscall. It's just… not a good idea.

Re: Io_uring, kTLS and Rust for zero syscall HTTPS server

#37

Post by maeln »

LAC-Tech wrote: post #33

I think rusts glacial compile times prevent it from being a useful platform for web apps. Yes it's a nice language, and very performant, but it's horrible devex to have to wait seconds for your server to recompile after a change.

> but it's horrible devex to have to wait seconds for your server to recompile after a change.

What a time to be alived that seconds to recompile is consider horrible devex.

Post reply on HN