Green threads explained in 200 lines of Rust
cfsamson.gitbook.io
Green threads explained in 200 lines of Rust
1–10 of 48 posts
Re: Green threads explained in 200 lines of Rust
#2Beautiful docs
Re: Green threads explained in 200 lines of Rust
#3The explanation of the asm! macro is great, I’ve always been a little confused by it.
It does make me thinking about how this could be useful in the context of Futures and async/await.
Re: Green threads explained in 200 lines of Rust
#4Isn't one downside that the inline assembly will not be peephole-optimized by the code generator (LLVM)? E.g., you'd be saving and restoring registers that are not even used.
Re: Green threads explained in 200 lines of Rust
#5Co-routines are very useful and likely underused, but sometimes you are actually better off being able to pass the control to a given thread directly, other than having a scheduler involved.
Anecdote: almost a decade ago, I was responsible for an NVMe-like implementation (hard- and software). The 3rd version of the firmware recognized the various components as threads, but there was no need for preemption (which would require expensive locking). Traditional scheduling would work, but you actually know exactly which thread should execute next (hardware will signal done), so an explicit yield_to() was far cheaper and only slightly more expensive than a function call.
Re: Green threads explained in 200 lines of Rust
#6Isn't one downside that the inline assembly will not be peephole-optimized by the code generator (LLVM)? E.g., you'd be saving and restoring registers that are not even used.
> a simple but working example
Re: Green threads explained in 200 lines of Rust
#7Isn't one downside that the inline assembly will not be peephole-optimized by the code generator (LLVM)? E.g., you'd be saving and restoring registers that are not even used.
> a simple but working example
Yeah, of course, but how would you work this type of code into something that can be used in production?
The goal should be to have a green thread library that you can just use without thinking about registers or assembly.
Re: Green threads explained in 200 lines of Rust
#8Co-routines are very useful and likely underused, but sometimes you are actually better off being able to pass the control to a given thread directly, other than having a scheduler involved. Anecdote: almost a decade ago, I was responsible for an NVMe-like implementation (hard- and software). The 3rd version of the firmware recognized the various components as threads, but there was no need for preemption (which woul…
If you have any knowledge of it, what are your thoughts about the Erlang scheduler & Erlang's concurrency model?
Re: Green threads explained in 200 lines of Rust
#9Earlier quoted context omitted.
> a simple but working example
Yeah, of course, but how would you work this type of code into something that can be used in production? The goal should be to have a green thread library that you can just use without thinking about registers or assembly.
> I’m not trying to make a perfect implementation here. I’m cutting corners to get down to the essence and fit it into what was originally intended to be an article but expanded into a small book.
lol
Re: Green threads explained in 200 lines of Rust
#10Earlier quoted context omitted.
> a simple but working example
Yeah, of course, but how would you work this type of code into something that can be used in production? The goal should be to have a green thread library that you can just use without thinking about registers or assembly.
> how would you work this type of code into something that can be used in production?
You wouldn't. There are production-ready solutions to this in many languages.
> The goal should be to have a green thread library that you can just use without thinking about registers or assembly.
The goal here is very explicitly to explain a concept by example, which is largely incompatible with what you say the goal should be. I think the author did a very good job.