wxPython and threads

[Benjamin]

I'm writing a search engine in Python with wxPython as the GUI. I have
the actual searching preformed on a different thread from Gui thread.
It sends it's results through a Queue to the results ListCtrl which
adds a new item. This works fine or small searches, but when the
results number in the hundreds, the GUI is frozen for the duration of
the search. I suspect that so many search results are coming in that
the GUI thread is too busy updating lists to respond to events. I've
tried buffer the results so there's 20 results before they're sent to
the GUI thread and buffer them so the results are sent every .1
seconds. Nothing helps. Any advice would be great.

 

[Stef Mientki]

I'm writing a search engine in Python with wxPython as the GUI. I have
the actual searching preformed on a different thread from Gui thread.
It sends it's results through a Queue to the results ListCtrl which
adds a new item. This works fine or small searches, but when the
results number in the hundreds, the GUI is frozen for the duration of
the search. I suspect that so many search results are coming in that
the GUI thread is too busy updating lists to respond to events. I've
tried buffer the results so there's 20 results before they're sent to
the GUI thread and buffer them so the results are sent every .1
seconds. Nothing helps. Any advice would be great.

maybe you'ld better ask this question in the wxPython discussion group:

(e-mail address removed)

cheers,
Stef

 

[Josiah Carlson]

I'm writing a search engine in Python with wxPython as the GUI. I have
the actual searching preformed on a different thread from Gui thread.
It sends it's results through a Queue to the results ListCtrl which
adds a new item. This works fine or small searches, but when the
results number in the hundreds, the GUI is frozen for the duration of
the search. I suspect that so many search results are coming in that
the GUI thread is too busy updating lists to respond to events. I've
tried buffer the results so there's 20 results before they're sent to
the GUI thread and buffer them so the results are sent every .1
seconds. Nothing helps. Any advice would be great.

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). Create a deque, and use append() and popleft().

To signal to the GUI thread that there are results available in your
deque, you can use wx.CallAfter(), which will be run in the GUI thread
when the event comes up. Alternatively, you can use a combination of
wx.PostEvent() and wx.lib.newevent (see:
http://wiki.wxpython.org/CustomEventClasses ) to pass the results, or
even just signal that 'more results are available in the deque'. I
would suggest merely signaling that more results are in the deque (using
wx.PostEvent() or wx.CallAfter()), as there are no guarantees on the
order of execution when events are posted (I have found that the event
queue sometimes behaves like a stack).

I would also suggest never polling any queue from the GUI thread. It's
wasteful. Just have it respond to an event (either explicitly from
wx.PostEvent() or implicitly with wx.CallAfter()).


- Josiah

 

[Iain King]

I'm writing a search engine in Python with wxPython as the GUI. I have
the actual searching preformed on a different thread from Gui thread.
It sends it's results through a Queue to the results ListCtrl which
adds a new item. This works fine or small searches, but when the
results number in the hundreds, the GUI is frozen for the duration of
the search. I suspect that so many search results are coming in that
the GUI thread is too busy updating lists to respond to events. I've
tried buffer the results so there's 20 results before they're sent to
the GUI thread and buffer them so the results are sent every .1
seconds. Nothing helps. Any advice would be great.

I do something similar - populating a bunch of comboboxes from data
takes a long time so I run the generator for the comboboxes in another
thread (and let the user use some textboxes in the mean time). A
rough edit toward what you might be doing:

import thread

class Processor(object):
def __init__(self):
self.lock = thread.allocate_lock()
self.alive = False
self.keepalive = False

def start(self):
if not self.alive:
self.alive = True
self.keepalive = True
thread.start_new_thread(self.Process, (None,))

def stop(self):
self.keepalive = False

def process(self, dummy=None):
self.alive = False


class SearchProcessor(Processor):
def __init__(self, entries, lookfor, report):
Processor.__init__(self)
self.entries = entries
self.lookfor = lookfor
self.report = report

def process(self, dummy=None):
for entry in self.entries:
if lookfor in entry:
self.report(entry)
if not self.keepalive:
break
self.report(None)
self.alive = False


results = []

def storeResult(result):
if result != None:
results.append(result)
else:
notifySomeMethod(results)

sp = SearchProcessor(someListOfData, someTextToSearchFor, storeResult)
sp.start()

when the search is done it will call notifySomeMethod with the
results. Meanwhile you could, for example, bind sp.stop() to a cancel
button to stop the thread, or add a counter to the storeResult
function and set a status bar to the total found, or whatever else you
want to do.

Iain

 

[Nick Craig-Wood]

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().

 

[Josiah Carlson]

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

 

[Nick Craig-Wood]

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.

You are right deque's do say they are thread safe - I didn't know
that. From the docs :-

Deques support thread-safe, memory efficient appends and pops from
either side of the deque with approximately the same O(1) performance
in either direction.

I think I'd go for the peace of mind option, but YMMV of course ;-)