Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Inlining assembly into slp_switch is fragile and compiler implementation-dependent #66
It's also particularly awkward to debug a problem in this code, since it heavily depends on what gcc generated and this is more difficult to read.
It seems to me that all of these issues would go away if
I understand that the
I'll leave it up to you. Feel free to close as "Won't Fix" - in this case I guess we'll just have to act when we see test failures.
(speaking of which, thank you for the tests, which picked up on these issues, and give me confidence that my workarounds work)
referenced this issue
Oct 14, 2014
Yes, I'm well aware of the issue, and full rewrite in assembly in the only proper solution. Unfortunately it's not that easy, one would need to call helper functions to do actual save/restore. I could do it for x86, then maybe for amd64 (harder, it needs to maintain stack alignment guarantees, which are impossible to know within
I don't have enough interest to do this, and in my opinion Go, Rust and proper coroutines are the future, not flimsy hacks like greenlet. Even if greenlet did switching perfectly, saving and restoring (or rather overwriting) stacks the way greenlet currently does is unsafe, which breaks gc, breaks threaded C++ code (global pointers to stack allocated objects become unsafe). And I'm sure no one would be thrilled if I moved to proper switching code (e.g. from Boost.Context), used separate stacks (would severely limit 32-bit architectures, e.g. no more than ~2000 greenlets), and dropped lots of architectures in the process. So until someone has enough itch to do the job we are left to working around smarter and smarter compilers.
Btw, pypy has a much better solution to this problem (but for a much smaller set of platforms), single asm block with pointers to save/restore functions. But it's not ideal either due to possibly incomplete clobber lists (callee saved registers are tricky) or potential stack alignment issues (which you can't maintain in
Not closing since the issue is true, and is awaiting its heroes.