A lock that times out but doesn't poll

Jive someone at microsoft.com
Thu Nov 25 20:51:44 CET 2004

I just took a look at Timer in threading.py.  Correct me if I'm wrong, but
it appears that the
timer always stays around for the programmed interval, even if cancel() is
called on it.  If that's the
case, it's hard for me to see how it could be used to implement a useful
timed lock.  The typical scenario
is for a thread to obtain a lock fairly quickly when things are functioning
properly, but to wait on it with
a long timeout in case some resource dries up -- like a socket connection
breaks.  In that scenario,
a thread that repeatedly waits on a timed lock will generate new Timer
threads faster than they will die off.

How can you use cancel() for [i]anything[/i]? In a time-sliced environment,
won't there
always be a race condition?

Once again, I have reservations about threading.py.  I do realtime
programming in my day job, so
I see bush-whackers behind every rhododendron.  Why, the stories I could
tell.  They would
make a grown man sick  Heck, they would make a sick man groan.

I looked for my pure Python version of timed locks, but I couldn't find it.
I'm wondering if I found
problems with *it* and deleted it.

I did find the MS-Windows timed lock extension though.

More information about the Python-list mailing list