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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com