Using threads

I want to write a program that has to do some long
taking calculations and want a window in which I
can see how it is progressing and some partial
results.

Now if I understand correctly this should be
handled by having two threads, one being the
windowhandler and the other being the calculator
which will send events to the windowhandler as
it is progressing and producing partial results.

Now my first idea was to use wxThread but a look
at the demo reveals that it is using thread from
the python library. So my questions are?

Is the wxThread usefull or should I stick to thread?

Are there any particular advantages to using thread
or wxThread or threading (which seems to be another
possibility from the python libarary)?

···

--
Antoon Pardon

I'm no threading expert, but as far as I understand,
they typical thing to do is to use the threading
module. See for instance

http://starship.python.net/crew/aahz/OSCON2001/index.html

···

At 11:05 2002-11-15 +0100, Antoon Pardon wrote:

Is the wxThread usefull or should I stick to thread?

Are there any particular advantages to using thread
or wxThread or threading (which seems to be another
possibility from the python libarary)?

--
Magnus Lycka, Thinkware AB
Alvans vag 99, SE-907 50 UMEA, SWEDEN
phone: int+46 70 582 80 65, fax: int+46 70 612 80 65
http://www.thinkware.se/ mailto:magnus@thinkware.se

Is the wxThread usefull or should I stick to thread?

Are there any particular advantages to using thread
or wxThread or threading (which seems to be another
possibility from the python libarary)?

Use threading, not thread. Threading is the higher level interface to thread
and is easier to use. Also, look at the Queue module. It's generally the
easiest way to pass events between threads without having to worry too much
about race conditions and deadlocks and whatnot.

-tim

But for sending information to the Window handler shouldn't I
stick to wxPostEvent? The Queue module seems very handy if
you have to synchronize multiple calculations or if you want
to communicate from the GUI thread to the others, but I have
the idea that in the specific case of sending something to
the GUI-thread I should make use of events. Am I missing
something?

···

On Fri, Nov 15, 2002 at 07:07:06AM -0700, Tim Hochberg wrote:

> Is the wxThread usefull or should I stick to thread?
>
> Are there any particular advantages to using thread
> or wxThread or threading (which seems to be another
> possibility from the python libarary)?

Use threading, not thread. Threading is the higher level interface to thread
and is easier to use. Also, look at the Queue module. It's generally the
easiest way to pass events between threads without having to worry too much
about race conditions and deadlocks and whatnot.

--
Antoon Pardon

Antoon Pardon wrote:

But for sending information to the Window handler shouldn't I
stick to wxPostEvent? The Queue module seems very handy if
you have to synchronize multiple calculations or if you want
to communicate from the GUI thread to the others, but I have
the idea that in the specific case of sending something to
the GUI-thread I should make use of events. Am I missing
something?

Either way works, and they are nearly equivallent. When you call wxPostEvent it adds the event object to a queue and wxWakeUpIdle is called, the queue is then emptied in the gui thread's idle time, and the event objects are dispatched to the handlers. When you use the Queue method you add some object onto the queue and call wxWakeUpIdle yourself, then your idle handler reads items from the queue and does something with them. See the similarity?

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Antoon Pardon wrote:

I want to write a program that has to do some long
taking calculations and want a window in which I
can see how it is progressing and some partial
results.

Now if I understand correctly this should be
handled by having two threads, one being the
windowhandler and the other being the calculator
which will send events to the windowhandler as
it is progressing and producing partial results.

Yes. There are also other ways to do it, see http://wiki.wxpython.org/index.cgi/LongRunningTasks for some of them.

Now my first idea was to use wxThread but a look
at the demo reveals that it is using thread from
the python library. So my questions are?

Is the wxThread usefull or should I stick to thread?

wxThread has not been wrapped into wxPython since Python already has the thread and threading modules.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

The best way to do this (after considerable experience trying
different ways is):

  * Define a custom event, with a progress field
  * Use the threading module to start a new thread
  * Use the event as your interface to the GUI, i.e,
    in the window with the progress bar, do an EVT_PROGRESS
    to catch the event.
  * Then update the progress bar in the event handler.

  I'd be happy to post some code if you have any more problems. In
general with threads, you should always use the event mechanism.
Using gui mutex locks get very messy, and is only appropriate for
quick and dirty work. It's also nice to define your events like
this:

  class wxMyEvent (wxPyEvent):

    def __init__ (self, **kwargs):
       wxPyEvent.__init__ (self)
       self.SetEventType (...)
       self.myfield = kwargs['myfield']

    def toHash (self):
       return { 'myfield' : self.myfield }

  with all your events. That way, for example, if your event
notification ends, you can easily create a new event for the
notifcation using the similar kwargs interface. Example:

  my_evt = ref_to_event
  kwargs = my_evt.toHash ()
  kwargs.update ({ 'other_opts' : 'some val' })
  other_evt = wxOtherEvent (**kwargs)

  That way, it's easy to chain events and event contents. Hope
that helps.

                      -- Mike

···

On Fri, Nov 15 @ 16:35, Antoon Pardon wrote:

On Fri, Nov 15, 2002 at 07:07:06AM -0700, Tim Hochberg wrote:
> > Is the wxThread usefull or should I stick to thread?
> >
> > Are there any particular advantages to using thread
> > or wxThread or threading (which seems to be another
> > possibility from the python libarary)?
>
> Use threading, not thread. Threading is the higher level interface to thread
> and is easier to use. Also, look at the Queue module. It's generally the
> easiest way to pass events between threads without having to worry too much
> about race conditions and deadlocks and whatnot.

But for sending information to the Window handler shouldn't I
stick to wxPostEvent? The Queue module seems very handy if
you have to synchronize multiple calculations or if you want
to communicate from the GUI thread to the others, but I have
the idea that in the specific case of sending something to
the GUI-thread I should make use of events. Am I missing
something?

--
Antoon Pardon

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org

--
Michael Gilfix
mgilfix@eecs.tufts.edu

For my gpg public key:
http://www.eecs.tufts.edu/~mgilfix/contact.html