Implement a futures-based condvar instead of using event for in-process eventing...

[todo]

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.

---

SunriseOS/sm/src/main.rs

Lines 72 to 82 in 269527c

	// TODO: Implement a futures-based condvar instead of using event for in-process eventing.
	// BODY: A futures-based condvar can easily be implemented entirely in userspace, without
	// BODY: the need for any kernel help. It would have a lot less overhead than using a kernel Event.
	/// Event signaled whenever a new service is registered. `get_service` waits on this event
	/// if the wanted service is not found, to try again when a new service comes up later.
	static ref SERVICES_EVENT: (WritableEvent, ReadableEvent) = {
	crate::libuser::syscalls::create_event().unwrap()
	};
	}
	/// Get the length of a service encoded as an u64.

---

This issue was generated by todo based on a TODO comment in 269527c when #384 was merged. cc @roblabla.

[kitlith]

we can probably steal this from async-rs/async-std#369 (or even use async-std, period)

[roblabla]

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.

[kitlith]

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.)

[roblabla]

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.