News for hackers. Stuff that matters.
Re:Async and Await in Rust: a full proposal by millstone on Sunday July 15, 2018 @04:27PM (#17536888)
Why would kernel threads be polling in practice? Won't most be waiting on locks, file descriptors, timers, etc?
Re:Async and Await in Rust: a full proposal by anko on Sunday July 15, 2018 @05:15PM (#17537121)
You're right, in theory, if your select() or epoll() doesn't have a timeout. And the threads aren't doing any active work. But if you're optimising for that state, then you don't care about inefficiencies of one model or another.

There are also costs in setting and checking those locks etc. Sure, you can build solutions to optimise a broken model, which we've done over decades (with quite a bit of success!), but it doesn't make the model less broken.

Re:Async and Await in Rust: a full proposal by xfer on Sunday July 15, 2018 @08:45PM (#17537964)
> But if you're optimising for that state, then you don't care about inefficiencies of one model or another.

Sure you do, there is noticable memory and ctx switching overhead(for large no. of them ofc) in stackful coroutines.