thread, threading, mutex modules and non-threading interpreters

[Aahz Maruch]

In article <39A60BEC.B5E431B at perspex.com>,
Tripp Lilley  <tripp at perspex.com> wrote:
>
>In the process of work on pieces of my library, I'm considering
>thread-safety issues (though I'm not doing anything about them yet :) ).
>Specifically, I wonder if it's possible to use thread and threading's
>various Lock mechanisms and have them "do the right thing", regardless
>of whether or not I'm running under a threading interpreter?
>
>The mutex module says that it doesn't depend on threads, but thread and
>threading say nothing about how they behave under a non-threading
>interpreter. Is it possible to make a "thread-aware", thread-safe module
>that doesn't /depend/ on threads?

There are two separate issues here.  First of all, I'm about 99.3%
certain that you cannot use anything from thread/threading if threads
are not compiled in.  You can't even import them.  As a side note, the
default for Python 2.0 will be to compile threads in.

Then there's the issue of being thread-safe or thread-aware.  You can't
do thread-aware unless you either require thread support or you write a
lot of scaffolding that does try/except on importing thread/threading
and makes the code work in non-thread-aware mode if it fails.

I'd suggest going for thread-safe.  Unless you absolutely need to share
resources between objects, it's easy to do: just make sure you don't use
any globals; make all your instances completely self-contained.
--
                      --- Aahz (Copyright 2000 by aahz at pobox.com)

Androgynous poly kinky vanilla queer het    <*>     http://www.rahul.net/aahz/
Hugs and backrubs -- I break Rule 6

The difference between "intelligence" and "wisdom": Londo and G'Kar  --Aahz