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

skip@pobox.com skip at pobox.com
Thu Oct 13 18:15:15 CEST 2005 

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

More information about the Python-Dev mailing list