threading module oddness
Tim Peters
tim at zope.com
Thu Dec 13 12:27:49 EST 2001
[Jason Orendorff]
> I've been kicking around in the threading.py source code.
>
> Two things:
>
> 1. In Condition, I noticed this code:
>
> class _Condition:
> ...
> def _is_owned(self):
> if self.__lock.acquire(0):
> self.__lock.release()
> return 0
> else:
> return 1
>
> According to the current documentation for the 'thread' module,
> the lock object should have a locked() method:
>
> def _is_owned(self):
> return self.__lock.locked()
threading != thread; Conditions are documented as requiring a threading.Lock
or threading.RLock, not a thread.lock, and the former define only .acquire()
and .release().
> 2. Wow, I had no idea what was going on under the hood here.
> Especially Condition.wait(). Wouldn't it be better if all this
> stuff were implemented using the native primitives?
Better according to what criteria? Certainly not better for maintainability
or clarity. Still, threading.Condition is a factory function rather than a
class precisely so that it would be *possible* to replace it with
platform-specific cruft someday (i.e., without needing to worry about
breaking user subclasses). Ditto all the other threading synch objects.
> How would a patch for that be received, assuming I could only help
> out with 1 or 2 platforms (pthread and NT)? (The rest could fall
> back on the current Python implementation for now.)
How it's received would depend on how portable and solid it was; e.g., there
are many flavors of pthreads kicking around, while the Windows API has some
useful synch primitives that don't actually exist on Win95. Sorting all
that out is time-consuming, delicate work, so try to enlist platform experts
to help. In the end, if the patch *only* kicked in for, say, Linux and
post-Win95 Windows, but was well-tested on those, and proved significantly
"better" (according to some objective criterion you have yet to identify
<0.5 wink>), that's the majority of actual Python platforms, so I'd say
"cool! good enough".
More information about the Python-list
mailing list