wxPython and threads

Benjamin wrote:

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:

wx************@ lists.wxwidgets .org

cheers,
Stef

On Jul 18, 3:41 am, Benjamin <musiccomposit. ..@gmail.comwro te:

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(objec t):
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_ne w_thread(self.P rocess, (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.__ini t__(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(ent ry)
if not self.keepalive:
break
self.report(Non e)
self.alive = False
results = []

def storeResult(res ult):
if result != None:
results.append( result)
else:
notifySomeMetho d(results)

sp = SearchProcessor (someListOfData , someTextToSearc hFor, storeResult)
sp.start()

when the search is done it will call notifySomeMetho d 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

Josiah Carlson <jo************ @sbcglobal.netw rote:

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

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick

Nick Craig-Wood wrote:

Josiah Carlson <jo************ @sbcglobal.netw rote:

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

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

Josiah Carlson <jo************ @sbcglobal.netw rote:

Nick Craig-Wood wrote:

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

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 ;-)

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick