Guido van Rossum discourseth: > > A strawman proposal: > > The uthread module provides the new functionality at the lowest level. I really like this as a primitive appropriate for Python's evolution. > - When func() returns, the uthread that was executing it ceases to be > runnable. The uthread that most recently yielded to it is resumed, > unless that is no longer runnable, in which case the uthread that > most recently yielded to *it* is resumed, and so on until a runnable > uthread is found or until no runnable uthreads are left, in which > case the program terminates. (XXX I need a proof here that this > works.) I'd like it added that when a uthread chains to its yielder it drops (i.e., nulls and decrefs) the reference to that yielder. I want uthreads in some of the same applications in which i disable gc for real-time purposes, and I don't want circular structures of unrunnable uthreads leaking my memory. > - Calling u.yield() or u.kill() for a non-runnable uthread is an error > and raises an exception. A runnable() predicate might be nice. > - I'm not sure that I got the start conditions right. Should func() be > be allowed to run until its first yield() when uthread.new(func) is > called? +1 for no on this. > - I'm not sure that the rules for returning and raising exceptions > from func() are the right ones. I'm particularly unsure about the exception propagation. It could always be disabled by a universal exception handler in the uthread, but I'm not sure it's even worth the implementation effort. > - Should it be possible to pass a value to another uthread by passing > an argument to u.yield(), which then gets returned by the resumed > yield() call in that uthread? Certainly! :) As written, the strawman seems to require that the dread intervening C stack frames are handled transparently (since it doesn't say anything about them). This seems pretty important to me. An instance method may well know that it should yield, yet not know that it's being called as a callback from a class/type that's just been moved to C. OTOH..not handling this transparently would increase my market value as a Python programmer. Handling it right might get me some unpaid work implementing some of the low-level details for Linux. Hmm! :D Eric
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4