[Python-Dev] threadtools (was Re: Autoloading? (Making Queue.Queue easier to use))

[skip@pobox.com]

    Nick> So the thread-related API would actually have three layers:
    Nick>    - _thread (currently "_thread") for the low-level guts
    Nick>    - threading for the basic thread API that any threaded app needs
    Nick>    - threadtools for the more complex "application-specific" items

    Nick> Initially threadtools would just contain Queue, but other candidates for 
    Nick> inclusion in the future might be standard implementations of:
    Nick>    - PeriodicTimer (see below)
    Nick>    - FutureCall (threading out a call, only blocking when you need the result
    Nick>    - QueueThread (a thread with "inbox" and "outbox" Queues)
    Nick>    - ThreadPool (up to the application to make sure the Threads are reusable)
    Nick>    - threading related decorators

Given your list of stuff to go in a threadtools module, I still think you
need something to hold Lock, RLock, Condition and Semaphore.  See my
previous post (subject: Threading and synchronization primitives) about a
threadutils module to hold these somewhat lower-level sync primitives.  In
most cases I don't think programmers need them.  OTOH, providing some higher
level abstractions seems to make sense.  (I have to admit I have no idea
what a QueueThread's outbox queue would be used for.  Queues are generally
multi-producer, single-consumer objects.  It makes sense for a thread to
have an inbox.  I'm not so sure about an outbox.)

Skip