threading.RLock not subclassible?

[Rick Lee]

It seems to me that OS-specific behaviour of thread switching is _very_
different among platforms.  For example, if the parent thread starts up 100
different threads each with some long loop to run:

    for i in xrange(100):
        try:
            t = threading.Thread(target=runObj, args=())
            t.start()
        except:
            break
    snapshot = threading.activeCount()

If I run it in different platforms, snapshot is consistently different, anywhere
between very close to 100, or just 1.  You may argue it depends on how long
runObj takes to run; but I can change runObj to run for a very long time, say
seconds, and the results are consistently different across the platforms (NT,
Mac, Linux).

I have some even weirder differences, if I use say time.sleep(.001) inside a
thread, as the FAQ says.  And I have a few other examples I ran across.  (The
one that bugs me the most is that some blocked threads in the Mac just don't get
to run, when the blocking condition is removed.)

This makes me very nervous about implementing a multi-thread cross-platform
application.

Anyone has a list of what the differences are across the platforms?

- Rick Lee

David Bolen wrote:

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