[Python-Dev] Last chance!

Christian Tismer tismer at tismer.com
Mon Dec 22 05:36:07 EST 2003

Tim Peters wrote:
> [Tim]
>>>Still, the possibility to switch threads across generator
>>>resumptions seems darned hard to view as "a feature".  I'd advise
>>>people not to rely on it <wink>.
> [Christian Tismer]
>>Well, this might only work for generators if it is guaranteed
>>that the thread switch doesn't happen while the generator
>>is executing. I think this will give an exception. But most
>>probably the result will be hard to predict.

Explaining that: I was talking about freely using
the generator in another thread, which would most
likely resume it while it is active, and that's
an exception.

> I'm not sure I'm following, but nothing in Python now *stops* you from
> resuming a suspended generator from another thread.  Here's an extreme
> example of that:

[XTreme example]

> Then the body of the single generator is executed by 3 different threads,
> more or less randomly, although never by the thread that created the
> generator.
> If the body of the generator were relying on thread-local state (like, e.g.,
> the mass of settings in the decimal arithmetic package's per-thread default
> "numeric context" object), the result would sure be unpredictable.  It
> wouldn't crash Python, it would just be a bitch to debug.  Then again, lots
> of bad threading practices lead to bitch-to-debug code, so I'm not really
> inclined to offer extra protection here.

I agree, sure, cross-thread generators need to
be designed for that.


> If a tasklet can be affected by thread-local state (like numeric context --
> Python has little of this nature now, but it's bound to increase), then a
> tasklet will also start to care "who's in charge".  So I expect a patch to
> reintroduce f_tstate in about a year <wink>.

It is already there, not in the frames, but in the tasklet.
A tasklet can be thread-bound or not. In that case, it
keeps a reference to the thread state. But only once,
since that information is not local for frames.
Being thead bound is either enforced in the case that
the tasklet is carrying non-trivial C state, otherwise it
can be set as a user option (conservative default, of course).
"Nomad threads" might be nice for some background monitoring.

This is all theory, I haven't tried any real threads
with Stackless so far. But people are mixing tasklets
with threads already, so I have to care *somehow*.

ciao - chris

Christian Tismer             :^)   <mailto:tismer at tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  mobile +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

More information about the Python-Dev mailing list