Sharing my notes in lieu of a blog post, I think I've figured out how to make MnemOS' executor work.
I have the rough shape of what the kernel ringbuffers need to look like, a hacked up version of bbqueue that is IPC safe, and an idea of what "mnemos-std" could look like.
Conversation
The fancy bits are made up of an intrusive linked-list MPSC library from (cordyceps, also used in her Mycelium OS), as well as a little static oneshot channel to make sure dropped futures don't lead to wasted resources.
Notes here:
2
1
8
One downside though (so far) is that leaning REALLY HARD into Rust's async/await is that I think it might be harder to provide a C/FFI interface for using other languages in MnemOS.
I'd probably have to go one of two ways:
1
3
1. Provide NOTHING, and expect the C library to "bring it's own concurrency", basically it gets access to the syscall api for sending/receiving messages, but it is responsible for "re-inventing the wheel" when it comes to scheduling, etc.
1
5
2. Provide EVERYTHING, basically have a "managed runtime" that does all the scheduling and stuff, and has some API or callbacks or something when things have completed successfully.
I'm not sure which is preferable, honestly.
3
4
Replying to
Could you build this second option later and first focus on getting other possibly more important things done?
1
1
Replying to
I mean honestly, my only non-Rust user is (maybe) , so I'll probably build 1 or 2 (based on what he prefers), or help him move completely over to Rust.
Or I'll note in the docs that these are possible options, and do them on-demand.
2
2
Btw I'm considering generating (unsafe) Rust instead of C and do glue in Rust.
1
1
And for C I do have my own concurrency libs...
Ping me when you're getting back into it, we'll work something out :)
1