[Python-Dev] uthread strawman
Tue, 7 Nov 2000 11:04:33 -0800 (PST)
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
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
+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?
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