Writing an OS in Rust: Async/Await
os.phil-opp.com
Writing an OS in Rust: Async/Await
1–10 of 107 posts
Re: Writing an OS in Rust: Async/Await
#2great project for this lull.
i've been going through http://craftinginterpreters.com/ in rust (in order to learn rust) and it's a fantastic learning experience. the language is straightforward after you understand the basics (smart pointers and generics) and if you have a good ide with completion (CLion). lifetimes/borrow checker aren't as painful as people would have you believe if you use heap allocation (i.e. Box, Rc). now obviously heap allocation isn't optimal but for getting started it enables a smooth progression.
Re: Writing an OS in Rust: Async/Await
#3This is also just a fantastic introduction to async/await in Rust, regardless of the OS bits. Another amazing article by Phil.
> The only requirement is that we use at least nightly 2020-03-25 of Rust because async/await was not no_std compatible before.
There's some fun stuff here that's omitted (which makes sense, of course). It was always a design constraint of async/await in Rust that you could use it without the standard library. However, the initial implementation required thread local storage. The future trait's poll method took a &mut Context, and generators didn't support passing context in to them when resuming. This meant that the context would be placed in TLS, and would pull it back out when needed. Generators are unstable, partially for this reason. However, this was fixed, and that means TLS is no longer a requirement here! See https://github.com/rust-lang/rust/pull/68524 for more details.
Re: Writing an OS in Rust: Async/Await
#4An OS with async/await sounds awfully similar to Windows 3.1 with its cooperative multitasking model.
What's old is new again ...
Re: Writing an OS in Rust: Async/Await
#5An OS with async/await sounds awfully similar to Windows 3.1 with its cooperative multitasking model. What's old is new again ...
Well, there's a big difference:
> Using async/wait, we now have basic support for cooperative multitasking in our kernel. While cooperative multitasking is very efficient, it leads to latency problems when individual tasks keep running for too long and thus prevent other tasks to run. For this reason, it makes sense to also add support for preemptive multitasking to our kernel.
> In the next post, we will introduce threads as the most common form of preemptive multitasking. In addition to resolving the problem of long running tasks, threads will also prepare us for utilizing multiple CPU cores and running untrusted user programs in the future.
It seems the plan here is to use this for internal work, and still give a preemptive multitasking API to userspace.
Re: Writing an OS in Rust: Async/Await
#6Is it possible to context switch between userspace processes directly, without going through the kernel, i.e. a kind of fast, inter-process cooperative multitasking? I know earlier operating systems used inter-process cooperative multitasking, but I'm guessing they still went through the scheduler?
I was trying to figure out if QNX does this with `MsgSend`, as QNX is renowned for being a fast microkernel, but it wasn't clear to me. According to Animats, "There's no scheduling delay; the control transfer happens immediately, almost like a coroutine. There's no CPU switch, so the data that's being sent is in the cache the service process will need." [1] According to wikipedia, "If the receiving process is waiting for the message, control of the CPU is transferred at the same time, without a pass through the CPU scheduler." [2]
It seems like `MsgSend` circumvents the scheduler, but does it circumvent context switching to the kernel entirely too?
Re: Writing an OS in Rust: Async/Await
#7An OS with async/await sounds awfully similar to Windows 3.1 with its cooperative multitasking model. What's old is new again ...
Well, I'm not well versed in the details, but I do wonder if cooperative multitasking isn't a better idea nowadays in the age of ubiquitous multicore.
Re: Writing an OS in Rust: Async/Await
#8Is it possible to context switch between userspace processes directly, without going through the kernel, i.e. a kind of fast, inter-process cooperative multitasking? I know earlier operating systems used inter-process cooperative multitasking, but I'm guessing they still went through the scheduler? I was trying to figure out if QNX does this with `MsgSend`, as QNX is renowned for being a fast microkernel, but it wasn…
No, it doesn't circumvent context switching to the kernel. With memory protection and separate address spaces, you generally need privileged execution to change page tables. However, the raw CPU cost of a syscall exception to the kernel followed by an exception return to userspace isn't actually all that high compared to all of the work that an OS usually does on top of it.
Re: Writing an OS in Rust: Async/Await
#9An OS with async/await sounds awfully similar to Windows 3.1 with its cooperative multitasking model. What's old is new again ...
Well, I'm not well versed in the details, but I do wonder if cooperative multitasking isn't a better idea nowadays in the age of ubiquitous multicore.
As Steve’s sibling comment points out, this is only for the kernel. The article mentions preemptive threading for the user space as still being desirable.
Re: Writing an OS in Rust: Async/Await
#10An OS with async/await sounds awfully similar to Windows 3.1 with its cooperative multitasking model. What's old is new again ...
Didn't most old operating systems use cooperative multitasking? I remember, at least, that classic Mac OS (i.e. pre-OSX) didn't use preemptive multitasking, either.
Anyway, this SO answer[0] explains why early Linux, much like the hobby kernel in this article, used cooperative scheduling inside the kernel, and only preempted user-space stuff.