threading module oddness

Tim Peters tim at zope.com
Thu Dec 13 18:27:49 CET 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