This document is a Mac OS X manual page. Manual pages are a command-line technology for providing documentation. You can view these manual pages locally using the man(1) command. These manual pages come from many different sources, and thus, have a variety of writing styles.

For more information about the manual page format, see the manual page for manpages(5).

Wx::Thread(3)                        User Contributed Perl Documentation                       Wx::Thread(3)



NAME
       Thread - using wxPerl with threads

SYNOPSIS
         # the order of these use()s is important
         use threads;
         use threads::shared;
         use Wx;

         my $DONE_EVENT : shared = Wx::NewEventType;

         my $worker = threads->create( \&work );

         # create frames, etc
         my $frame = Wx::Frame->new( ... );
         EVT_COMMAND( $frame, -1, $DONE_EVENT, \&done );
         $app->MainLoop;

         sub done {
             my( $frame, $event ) = @_;

             print $event->GetData;
         }

         sub work {
             # ... do stuff, create a shared $result value

             my $threvent = new Wx::PlThreadEvent( -1, $DONE_EVENT, $result );
             Wx::PostEvent( $frame, $threvent );
         }

         # event handler
         sub OnCreateThread {
             # @_ = () is necessary to avoid "Scalars leaked"
             my( $self, $event ) = @_; @_ = ();

             threads->create( ... );
         }

DESCRIPTION
       Threaded GUI application are somewhat different from non-GUI threaded applications in that the main
       thread (which runs the GUI) must never block.  Also, in wxWidgets, no thread other than the main
       thread can manipulate GUI objects.  This leads to a hybrid model where worker threads must send
       events to the main thread in order to change the GUI state or signal their termination.

       Order of module loading

       It's necessary for "use Wx" to happen after <use threads::shared>.

       Sending events from worker threads

       "Wx::PlThreadEvent" can be used to communicate between worker and GUI threads.  The event can carry a
       shared value between threads.

         my $DONE_EVENT : shared = Wx::NewEventType;

         sub work {
             # ... do some stuff
             my $progress = new Wx::PlThreadEvent( -1, $DONE_EVENT, $progress );
             Wx::PostEvent( $frame, $progress );

             # ... do stuff, create a shared $result value
             my $end = new Wx::PlThreadEvent( -1, $DONE_EVENT, $result );
             Wx::PostEvent( $frame, $end );
         }

       The target of the event can be any "Wx::EvtHandler"

       Receiving events from worker threads

       "Wx::PlThreadEvent" is a command event and can be handled as such.  The "->GetData" method can be
       used to retrieve the shared data contained inside the event.

         my $DONE_EVENT : shared = Wx::NewEventType;

         EVT_COMMAND( $frame, -1, $DONE_EVENT, \&done );

         sub done {
             my( $frame, $event ) = @_;

             print $event->GetData;
         }

       Creating new threads

       Creating new threads from event handlers works without problems except from a little snag.  In order
       not to trigger a bug in the Perl interpreter, all event handler that directly or indirectly cause a
       thread creation must clean @_ before starting the thread.

       For example:

         sub OnCreateThread {
             my( $self, $event ) = @_; @_ = ();

             threads->create( ... );
         }

       failure to do that will cause "scalars leaked" warnings from the Perl interpreter.



perl v5.8.8                                      2007-03-16                                    Wx::Thread(3)