Nick Craig-Wood wrote: > Josiah Carlson <[EMAIL PROTECTED]> wrote: >> Sending results one at a time to the GUI is going to be slow for any >> reasonably fast search engine (I've got a pure Python engine that does >> 50k results/second without breaking a sweat). Don't do that. Instead, >> have your search thread create a list, which it fills with items for >> some amount of time, *then* sends it off to the GUI thread (creating a >> new list that it then fills, etc.). While you *could* use a Queue, it >> is overkill for what you want to do (queues are really only useful when >> there is actual contention for a resource and you want to block when a >> resource is not available). > > I'd dispute that. If you are communicating between threads use a > Queue and you will save yourself thread heartache. Queue has a non > blocking read interface Queue.get_nowait().
If you have one producer and one consumer, and the consumer will be notified when there is an item available, AND deques (in Python 2.4, 2.5, and presumably later) are threadsafe, then the *additional* locking, blocking, etc., that a Queue provides isn't necessary. Whether one wants to use a Queue for 'piece of mind', or for future expansion possibilities is another discussion entirely, but his application (as stated) will work with a deque for the worker thread -> GUI thread communication path. - Josiah -- http://mail.python.org/mailman/listinfo/python-list
