wx::thread(3pm) [debian man page]

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

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.14.2							    2007-03-16							   Wx::Thread(3pm)

Check Out this Related Man Page

pods::SDL::Time(3pm)					User Contributed Perl Documentation				      pods::SDL::Time(3pm)

NAME

       SDL::Time - An SDL Perl extension for managing timers

CATEGORY

       Core

SYNOPSIS

	use warnings;
	use strict;

	use threads;
	use threads::shared;

	use SDL::Time;

	package foo;

	use SDL ':all';

	SDL::init(SDL_INIT_TIMER);

	my $tick :shared = 0;
	sub ticker { $tick++; warn $tick; return 100; }

	package main;

	my $id = SDL::Time::add_timer(100, 'foo::ticker');

	sleep(2);

	SDL::Time::remove_timer($id);

METHODS

   add_timer
	my $id = SDL::Timer::add_timer( $ms_interval, $callback );

       This runs in a separate thread and a cloned Perl thread.  "threads" and "threads::shared" must be used to share any variables the timer
       uses.

       The $callback function, specified with a string of the function's name, will be called after the milliseconds of $interval have elapsed.
       The actual delay may be longer than specified depending on the underlying OS.  The callback function is passed the current timer interval
       as well as the $interval parameter and should return the next timer interval.  If the return value from the callback is 0, the timer is
       cancelled; otherwise, the timer will continue to run.

       The timer callback function may run in a different thread to your main program, so it shouldn't call any functions from within itself.  You
       may call SDL::push_event, however.

       "SDL::Time::add_timer" returns the identifier value of the generated timer or undef on error.

       Note: You must initialize ("SDL::init") the timer subsystem to use this function.

   remove_timer
	SDL::Timer::remove_timer( $id );

       The other way to cancel a timer is to use "SDL::Time::remove_timer" on the $id of a timer.  This ID is the return value of the
       "SDL::Time::add_timer" function.

       "SDL::Time::remove_timer" returns 0 on success or "-1" on error.

AUTHORS

       See "AUTHORS" in SDL.

perl v5.14.2							    2012-05-28						      pods::SDL::Time(3pm)

Linux and UNIX Man Pages

wx::thread(3pm) [debian man page]

Check Out this Related Man Page