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.
I don't know how practical that optimization would be in this particular use case, wouldn't that mean the context switch code would have to be inlined at every call site? Then when you switch back to that context how would you generate that code correctly? You would need to know which registers were not saved by green thread A, and not touched by green thread B. So the compiler would basically need to know the runtime behavior of your program to optimize pushing and popping context records, unless I misunderstood your point?
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.
> 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.
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...
> Going for "toy" code to production ready is hard.
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.
> 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.
