Dag Sverre Seljebotn, 22.05.2011 21:48:
Keep in mind that if speed is the objective, another idea is to use real C
coroutines. This would likely be faster than anything we can make up
ourselves; a single stack jump is bound to be faster than copying things in
and out of the stack.
Of course, probably more work. And then portability as the API is seperate
for Windows (fibers) and POSIX (makecontext). But I don't think there's a
lack of compatability layer libraries which unite the platform-specific APIs.
What if we have to call back into CPython? Would that work if the call ends
up on a different stack than previous ones? What about CPython thread
switches and signal handlers?
Wikipedia has a couple of things to say about coroutines in C:
http://en.wikipedia.org/wiki/Coroutine#Implementations_for_C
including links to some libraries that are supposed to be portable:
http://xmailserver.org/libpcl.html
http://software.schmorp.de/pkg/libcoro.html
http://code.google.com/p/libconcurrency/
http://www.dekorte.com/projects/opensource/libCoroutine/
http://www.goron.de/~froese/coro/
Overall, I think this has some potential but also major uncertainties. And
it's a substantially larger change than making local variables C variables.
May have made a good GSoC topic...
Stefan
_______________________________________________
cython-devel mailing list
cython-devel@python.org
http://mail.python.org/mailman/listinfo/cython-devel
