Stackless Python, eventual merge?
tismer at tismer.com
Thu Sep 19 20:02:52 CEST 2002
Martin v. Löwis wrote:
> Christian Tismer <tismer at tismer.com> writes:
>>Maybe sufficient for not crashing on the C level.
>>But this is not enough for micro-thread-safety.
>>See the random module for example, it needs a lock
>>or it will give unpredictable results.
> Academically, I don't think the results are unpredictable, as
> micro-thread switch occur at predictable points in processing.
Yes, right now, but this will change pretty soon.
> Regardless, you are saying that the random module is not
> thread-safe. A number of Python modules is not thread safe; many of
> them won't be 'safe' in the presence of microthreads, either. With
> microthreads, the problem is usually not as bad as with real threads,
> since a switch usually cannot occur in the middle of a library routine
> (unless the library calls back, and the call-back causes a switch).
I am not saying that the random module is not thread safe (although
I'm not sure if it is). The point is: Microthread safety is more
than thread safety, since microthreads don't care about thread
locks, since they are still *in the same thread*.
It will for sure become a problem, and it is different from
effect, but similar to the C probs by reason: We are switching
context where some code might not expect it. It might feel safe
because it is thread safe, but this is not enough.
I have to do rigid locking of every unknown piece of code,
until somebody explicitly claims some code to be switchable.
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 pager +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-list