By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,606 Members | 2,016 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,606 IT Pros & Developers. It's quick & easy.

wxPython and threads

P: n/a
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.

Jul 18 '07 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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
Jul 18 '07 #2

P: n/a
On Jul 18, 3:41 am, Benjamin <musiccomposit...@gmail.comwrote:
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

Jul 19 '07 #3

P: n/a
Josiah Carlson <jo************@sbcglobal.netwrote:
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().

--
Nick Craig-Wood <ni**@craig-wood.com-- http://www.craig-wood.com/nick
Jul 19 '07 #4

P: n/a
Nick Craig-Wood wrote:
Josiah Carlson <jo************@sbcglobal.netwrote:
> 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
Jul 19 '07 #5

P: n/a
Josiah Carlson <jo************@sbcglobal.netwrote:
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_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.
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
Jul 19 '07 #6

This discussion thread is closed

Replies have been disabled for this discussion.