[Python-Dev] Threading and synchronization primitives

[skip@pobox.com]

    Greg> All right then, how about putting it in a module called
    Greg> threadutils or something like that, which is clearly related to
    Greg> threading, but is open for the addition of future thread-related
    Greg> features that might arise.

Then Lock, RLock, Semaphore, etc belong there instead of in threading don't
they?

We have two things here, the basic thread object and the stuff it does (run,
start, etc) and the synchronization primitives.  Thread objects come in two
levels of abstraction: thread.thread and threading.Thread.  The
synchronization primitives come in three levels of abstraction: thread.lock,
threading.{Lock,Semaphore,...} and Queue.Queue.  Each level of abstraction
builds on the level below.

In the typical case I think we want to encourage programmers to use the
highest levels of abstraction available and leave the lower level stuff to
the real pros.  That means most programmers using threads should use
threading.Thread and Queue.Queue.  Partitioning the various classes to
different modules might look like this:

        Module        Thread Classes            Sync Primitives
        ------        --------------            ---------------
        _thread       thread                    lock
        threadutils                             Lock, RLock, Semaphore
        thread        Thread                    Queue

Programmers would clearly be discouraged from using the _thread module
(currently thread).  The typical case would be to import the thread module
(currently threading) and use its Thread and Queue objects.  For specialized
use the threadutils programmer can import the threadutils module to get at
the synchronization primitives it contains.

Skip