semaphores and Rlocks

[Aahz]

In article <3E03C7D5.1285B21A at sdfasdfasdfa.invalid>,
Jive Dadson  <sdfadfsa at sdfasdfasdfa.invalid> wrote:
>Aahz wrote:
>> In article <3E03A3F7.2AD7A028 at sdfasdfasdfa.invalid>,
>> Jive Dadson  <sdfadfsa at sdfasdfasdfa.invalid> wrote:
>>>
>>>Yeah.  Win32 CRITICAL_SECTION is implemented the same way, with
>>>an interlocked increment wrapped around a win32 Mutex.  But
>>>CRITICAL_SECTION allows a thread to acquire the a lock repeatedly.
>>>
>>>By the way, I noticed some comments about not having
>>>InterlockedIncrement or something like that available on Win98.  I can
>>>furnish an assembly language version in a C "__asm" thingy if anyone is
>>>interested.  It would be just about as "portable" as the win32 API.
>> 
>> Someone in the past year on either c.l.py or python-dev was talking
>> about writing some improvements to thread_nt.h, but I can't find it in a
>> few minutes of Googling.  If you can find that person and talk with him,
>> that might be a good first step.
>
>Improving that stuff wouldn't do the trick.  The problem is that no
>Python synchronization primitive has a timeout.

You can't fix your problem without fixing thread_nt.h.  Python's
higher-level synch constructs are all built on a virtual lock()
construct that doesn't have a timeout.  Python uses a virtual lock() so
that there's relatively little platform-specific code -- and none in
threading.py or Queue.py.  That virtual lock() needs to change in order
to implement the feature you want.  If you want the standard library to
get updated, you'll also need to make sure that Posix threads get a
similar fix.

BTW, would you please fix your Netscape so that lines are 75 columns or
less?
-- 
Aahz (aahz at pythoncraft.com)           <*>         http://www.pythoncraft.com/

"To me vi is Zen.  To use vi is to practice zen.  Every command is a
koan.  Profound to the user, unintelligible to the uninitiated.  You
discover truth everytime you use it."  --reddy at lion.austin.ibm.com