IPC Server based on future executor #384
Conversation
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. Lines 72 to 81 in 10bf5f6 This comment was generated by todo based on a
|
Find a way to clean up the shared service handles.Service handles returned by `new()` are valid throughout the lifetime of the process. Currently, they get cleaned up automatically on process exit. This is not ideal: resources should get automatically cleaned up through the appropriate calls to CloseHandle (especially for "real" homebrew, which don't automatically release leaked resources). SunriseOS/swipc-gen/src/gen_rust_code.rs Lines 800 to 810 in 10bf5f6 This comment was generated by todo based on a
|
time/build-script/Cargo.toml
Outdated
| flate2 = { version = "1.0", features = ["rust_backend"] } |
Move sm::ServiceName inside sunrise_libuser::sm.Sm has a ServiceName transparent struct that allows easy displaying of u64-encoded service names. Ideally, ServiceName should be generated by swipc-gen, and libuser would inject a Display implementation in it. Lines 107 to 117 in 306d95b This comment was generated by todo based on a
|
Footgun: Sharing ServerPorts can result in blocking the event loopIf the user shares ServerPorts across threads/futures and does something like calling accept straight after wait_async, they might end up blocking the event loop. This is because two threads might race for the call to accept after the wait_async. SunriseOS/libuser/src/types.rs Lines 351 to 361 in da88164 This comment was generated by todo based on a
|
There's no reason to force proxy functions to use a &mut self, since sendSyncRequest only takes a &self. Multiple IPC requests will get queued up by the kernel, and sent one after the other.
Introduce a Proxy::new() function, which caches the returned handle to avoid creating new handles each time we need to access a service. Those handle will be kept in a static Once, and never get dropped. NOTE: We will want to eventually find a way to clean up the handles on process exit.
WaitSynchronization should not reschedule when called with a timeout of 0. This allows using waitsync as a way to check if a handle is signaled in a non-blocking way, which will become very important. Additionally, it allows using ReplyAndReceive in a non-blocking way.
Spurious interrupts are now prevented by having the wait_async function do a non-blocking check that the handle is, indeed, signaled before returning Ready. This should allow using Futures with select, along with making us more robust against being woken up erroneously. We separately make sure to clean up wait handles on task completion, to avoid unbounded memory growth.
We now unregisters the current task from waiting when dropping the future returned by wait_async. This should avoid various spurious wakeups conditions.
After hitting so many lifetime errors, deadlocks, and weird compiler bugs, we're finally there: A futures implementation that works!
Note that this is based on a snapshot of @Orycterope's TLS work, which is not ready for prime-time (yet). It will get rebased on master once TLS is merged in.
There are still a few things to be done: We're missing a metric shitton of documentation, the future executor should be split from the IPC implementation, etc...