threading module oddness

[Jason Orendorff]

Tim,

Thanks for the great response!

> 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().

Hmm.  I had not realized this.  Good point.

[Strangely enough, what I wrote would work anyway, due to some
other strangeness in the implementation.  Two wrongs make a right!]


> > 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.

Excellent question.  Here's what I had in mind:

1.  Performance factors: wall clock time and CPU usage.
    Here's one guy's measure of how Condition.wait() performs:
       http://www.bagley.org/~doug/shootout/bench/prodcons/

2.  Principle of least surprise.  I think a guy who's done some
    thread programming on Linux before, would likely expect Condition
    to behave as though it had a pthread cond object inside -- on
    Linux anyway.  ("Surely they're not duplicating kernel-level
    features in Python...")  I'm no guru, but I'm guessing this
    assumption could lead to the occasional subtle bug.

3.  Clarity.  I think the threading code for any given platform will
    be simpler and shorter than the existing threading.py code.

Just for giggles, I'm currently writing a "winthreading.py" module
that uses win32event.  We'll see how it goes.

-- 
Jason Orendorff