Josiah Carlson <[EMAIL PROTECTED]> wrote:
> 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 co
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,
>> h
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
On Jul 18, 3:41 am, Benjamin <[EMAIL PROTECTED]> 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 work
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
>
Sounds like a race condition. is List Ctrl waiting for the gui to return?
Maybe make the processing more then one thread!
On 7/17/07, Stef Mientki <[EMAIL PROTECTED]> wrote:
Benjamin wrote:
> I'm writing a search engine in Python with wxPython as the GUI. I have
> the actual searching preformed
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
>
David E. Konerding DSD staff wrote:
> http://wxwidgets.org/manuals/2.6.1/wx_threadfunctions.html#threadfunctions
>
> This strongly suggests you can arbitrarily grab the wx GUI lock and call GUI
> functions from any thread. It's still voodoo. But we're adults here, and
> practicing
> voodoo isn'
On 2005-08-10, Peter Hansen <[EMAIL PROTECTED]> wrote:
> David E. Konerding DSD staff wrote:
>> Further, calling wx from a thread other than the one running the event
> > loop is deep voodoo and should typically be avoided.
>
> "Typically"? Let's just say "always" and maybe use the phrase "certai
On 2005-08-10, Bryan Olson <[EMAIL PROTECTED]> wrote:
> > The easiest approach, though, is to use the threadedselectreactor in
> Twisted (you need
> > to check the HEAD branch out with subversion, because that reactor
> isn't included in any releases).
> > With threadedselectreactor, it's easy to
David E. Konerding DSD staff wrote:
> The easiest approach, though, is to use the threadedselectreactor in Twisted
> (you need
> to check the HEAD branch out with subversion, because that reactor isn't
> included in any releases).
> With threadedselectreactor, it's easy to incorporate both the GU
Peter Hansen wrote:
> David E. Konerding DSD staff wrote:
>> Further, calling wx from a thread other than the one running the
>> event loop is deep voodoo and should typically be avoided.
>
> "Typically"? Let's just say "always" and maybe use the phrase "certain
> to corrupt wx and crash the
thanks for all these advices.
I think a custom event will be the way to go.
for the moment I use something _really_ ugly : a mix between GUI,
threads and recursive fonctions.
--
http://mail.python.org/mailman/listinfo/python-list
David E. Konerding DSD staff wrote:
> Further, calling wx from a thread other than the one running the event
> loop is deep voodoo and should typically be avoided.
"Typically"? Let's just say "always" and maybe use the phrase "certain
to corrupt wx and crash the app" instead of "deep voodoo".
David E. Konerding DSD staff wrote:
[...]
> You need another way to pass completion information between the
downloader
> thread and the main thread; the simplest way is to define a custom wx
> Event, and wxPostEvent from the downloader thread when it completes (
> and when the gauge should be
In article <[EMAIL PROTECTED]>, perchef wrote:
> Hi,
>
> I have several files to download and a GUI to update. I know this is a
> frequently asked question but i can't find an appropriate solution.
> My Downloader extends threading.Thread and update a wx.Gauge in GUI
> during the process.
>
> for
16 matches
Mail list logo
