sunriseos
Implement a futures-based condvar instead of using event for in-process eventing...
A futures-based condvar can easily be implemented entirely in userspace, without the need for any kernel help. It would have a lot less overhead than using a kernel Event.
https://github.com/sunriseos/SunriseOS/blob/269527c169b3b607532af4357ba272e3ff9f6fed/sm/src/main.rs#L72-L82
This issue was generated by todo based on a TODO comment in 269527c169b3b607532af4357ba272e3ff9f6fed when #384 was merged. cc @roblabla.
![todo[bot] avatar](https://avatars.githubusercontent.com/in/5534?v=4 "Published by a pub.dev verified publisher"){kind=small}
we can probably steal this from https://github.com/async-rs/async-std/pull/369 (or even use async-std, period)
async-std probably relies on mio, and a ton of other stuff. We’d need to port it.
Honestly, I kinda like my little executor. It’s dumb simple to understand. Tokio/AsyncStd have an insane amount of hidden state and magic algorithms that makes me super uncomfortable to use. There are a lot of stuff I have plans for on the executor side of things (such as moving a ton of heap allocation to statics, etc...) that would be hard to do with tokio at least (and probably asyncstd too but I wouldn’t know for sure).
Regarding the linked condvar impl, if it works as is, cool, but I’d be surprised. After a cursory glance, I think the wait function is broken. See, just because the poll function is called doesn’t mean the condvar was necessarily signaled. For instance, it’s possible to poll two things at once (futures-rs has an adapter for it). Yet their impl seems to heavily rely on that. My old code for waiting on ReadableEvents did too, and caused me endless pain.
You could try asking for clarification, etc. about that? If it's broken I'm sure they would appreciate you pointing it out. (I'm not going to do so because I don't know enough about this topic.)
So, erm, looked at it again at not-3-AM. It's not actually broken because condvars are allowed to spuriously wake up. I still think it's a huge footgun, but we could probably take their impl and just make the wait/wait_timeout function private, forcing users to pass a callback function providing the actual wait semantics.
Sent a comment about it.