thread, threading, mutex modules and non-threading interpreters 
Author Message
 thread, threading, mutex modules and non-threading interpreters

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?

Thanks!

--

http://www.*-*-*.com/ ~tlilley/
-----------------------------------------------------------------------------
"This whole textual substitution thing is pissing me off.
 I feel like I'm programming in Tcl."

- Eric Frias, former roommate, hacking partner extraordinaire



Tue, 11 Feb 2003 14:02:20 GMT  
 thread, threading, mutex modules and non-threading interpreters


Quote:

>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.
--

Androgynous poly {*filter*} vanilla {*filter*} het    <*>     http://www.*-*-*.com/
Hugs and backrubs -- I break Rule 6

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



Tue, 11 Feb 2003 03:00:00 GMT  
 thread, threading, mutex modules and non-threading interpreters

Tripp Lilley schreef:

Quote:
> 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.

They are simply not there, so you could do something like this:

try:
    from threading import Lock
except ImportError:
    class Lock:
        def acquire(self, blocking=1):
            if not blocking:
                return 1
        def release(self): pass

--
Niels Diepeveen
Endea automatisering



Tue, 11 Feb 2003 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Threads creating threads creating threads...

2. Non-threaded function in a threaded recursion?

3. Threading and non-threading python

4. Threaded Tcl calls non-thread-safe library functions

5. Thread safe tcl: interpreter per thread?

6. JPython Threading module fully free-threaded???

7. Can --with-thread enable the thread module?

8. Communications/Threading/Mutexes Classes and Specification

9. timeout within Threads (do I need a mutex?)

10. A current thread reentrant Mutex

11. thread::mutex lock problem, a bug?

12. Thread.new vs. Thread.start

 

 
Powered by phpBB® Forum Software