threading.RLock not subclassible?

[David Bolen]

"Tim Peters" <tim.one at home.com> writes:

> BTW, an acquire with a timeout is a cool idea!  Feel encouraged to submit a
> patch to add such a thing directly to threading.py:

If anyone does think along these lines I'd suggest investigating
adding a timeout to the code per-platform thread code as opposed to
something at a high level in threading.py.

Using a loop construct around a non-blocking lock acquisition runs the
risk of never getting the lock, even if you were the first to start
waiting, such as in the case where you are in the loop part of the
code when the lock releases.

What's really needed is a true blocking acquire with timeout, so that
you remain constantly in the queue for the lock at the OS level, and
are guaranteed to get it if it frees up within your timeout.

For systems where that isn't supported at the OS level, the
non-blocking loop could be implemented in the appropriate thread_* OS
module.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/