Isn'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.
If you set a breakpoint in say a win32 fiber switch, and look at the disassembly, it jumps to an internal function that just saves all the registers (and flags) to the active context and restores all the registers from the resumed context every time. Don't know how more optimal that can be for the general case.
You potentially don't know who is "resuming", and so don't know what registers they will clobber. It would only be a "downside" if 1) your code uses a register 2) no other possible green threads do, and that isn't an invariant any compiler I know will promise, especially in the face of FFI calls.
If you're at the point where you want to do register allocation and spilling optimization across multitasking points, you're probably better off writing your own compiler instead of expecting a thread runtime to do it for you.
For comparison, normal threads have the same downside: the kernel saves and restores all registers (even more than what the example does), so you're not doing any worse than that.
The goal should be to have a green thread library that you can just use without thinking about registers or assembly.
lol
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.
I wasn't questioning that!
Why would you?
> The goal should be to have a green thread library that you can just use without thinking about registers or assembly.
No it should not. That's a completely separate (and mostly incompatible) goal than TFA's, which is educational.
Also, rust already have several options for concurrency/parallelism that are more idiomatic.
The only reason I see is to have a coroutine library for build a language, yet I have wonder if I put a facade of Actix actors or similar for this case...
Too true. I recently implemented a feature, and I had a standalone working version 90% complete in a day or two. Getting the thing solid, tested, and integrated took the better part of a month.
Part of that, I think, is our education model. Every project I ever had in school was started from scratch, I worked on it for a short period of time, turned it in, and never looked at it again. I got really good at that. I can write a toy version of a hard problem in a very short period of time. But I'm terrible at integrating those things into a larger whole, and I know for a fact I'm not alone in this.
I think it's a huge problem that corporations think that a CS degree is job training and won't hire you if you haven't done it, but colleges think it's about abstract concepts and research and don't teach engineering principles.