threading.RLock not subclassible?

[David Bolen]

aahz at panix.com (Aahz Maruch) writes:

> Given how little of Python is currently platform-specific, what kinds of
> arguments can you marshal in favor of this?

At the high level library layer there isn't much, but there's a decent
amount of platform code within the core itself.  An admirably small
amount to be sure, but thread support is one of those areas where it's
hard to avoid.

In particular, the low level thread support is already
platform-specific in the core (see all the thread_xxx.c modules),
including the lock acquisition we're talking about modifying, so I
don't think that having a platform-specific implementation of a new
timeout parameter is much of a difference at all implementation wise.

Note that the existence of the timeout parameter would be
platform-independent, and the existing core OS modules would just use
the native support if present or implement a non-blocking loop if not.
You could probably abstract that non-blocking loop as a single piece
of code for all thread modules that needed it.  For many cases it
would be a trivial change to the core code (e.g., under Windows just
passing on the timeout parameter rather than the current hardcoded
INFINITE if a blocking acquisition was used).

--
-- 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     \
\-----------------------------------------------------------------------/