view release on metacpan or  search on metacpan

lib/threads.pm  view on Meta::CPAN

  ... # Main thread continues working

=item Parent-child threads

On some platforms, it might not be possible to destroy I<parent> threads while
there are still existing I<child> threads.

=item Unsafe signals

Since Perl 5.8.0, signals have been made safer in Perl by postponing their
handling until the interpreter is in a I<safe> state.  See
L<perl58delta/"Safe Signals"> and L<perlipc/"Deferred Signals (Safe Signals)">
for more details.

Safe signals is the default behavior, and the old, immediate, unsafe
signalling behavior is only in effect in the following situations:

=over 4

=item * Perl has been built with C<PERL_OLD_SIGNALS> (see C<perl -V>).

=item * The environment variable C<PERL_SIGNALS> is set to C<unsafe>
(see L<perlrun/"PERL_SIGNALS">).

=item * The module L<Perl::Unsafe::Signals> is used.

=back

If unsafe signals is in effect, then signal handling is not thread-safe, and
the C<-E<gt>kill()> signalling method cannot be used.

=item Identity of objects returned from threads

When a value is returned from a thread through a C<join> operation,
the value and everything that it references is copied across to the
joining thread, in much the same way that values are copied upon thread
creation.  This works fine for most kinds of value, including arrays,
hashes, and subroutines.  The copying recurses through array elements,
reference scalars, variables closed over by subroutines, and other kinds
of reference.

However, everything referenced by the returned value is a fresh copy in
the joining thread, even if a returned object had in the child thread
been a copy of something that previously existed in the parent thread.
After joining, the parent will therefore have a duplicate of each such
object.  This sometimes matters, especially if the object gets mutated;
this can especially matter for private data to which a returned subroutine
provides access.

=item Returning blessed objects from threads

Returning blessed objects from threads does not work.  Depending on the classes
involved, you may be able to work around this by returning a serialized
version of the object (e.g., using L<Data::Dumper> or L<Storable>), and then
reconstituting it in the joining thread.  If you're using Perl 5.10.0 or
later, and if the class supports L<shared objects|threads::shared/"OBJECTS">,
you can pass them via L<shared queues|Thread::Queue>.

=item END blocks in threads

It is possible to add L<END blocks|perlmod/"BEGIN, UNITCHECK, CHECK, INIT and
END"> to threads by using L<require|perlfunc/"require VERSION"> or
L<eval|perlfunc/"eval EXPR"> with the appropriate code.  These C<END> blocks
will then be executed when the thread's interpreter is destroyed (i.e., either
during a C<-E<gt>join()> call, or at program termination).

However, calling any L<threads> methods in such an C<END> block will most
likely I<fail> (e.g., the application may hang, or generate an error) due to
mutexes that are needed to control functionality within the L<threads> module.

For this reason, the use of C<END> blocks in threads is B<strongly>
discouraged.

=item Open directory handles

In perl 5.14 and higher, on systems other than Windows that do
not support the C<fchdir> C function, directory handles (see
L<opendir|perlfunc/"opendir DIRHANDLE,EXPR">) will not be copied to new
threads. You can use the C<d_fchdir> variable in L<Config.pm|Config> to
determine whether your system supports it.

In prior perl versions, spawning threads with open directory handles would
crash the interpreter.
L<[perl #75154]|http://rt.perl.org/rt3/Public/Bug/Display.html?id=75154>

=item Detached threads and global destruction

If the main thread exits while there are detached threads which are still
running, then Perl's global destruction phase is not executed because
otherwise certain global structures that control the operation of threads and
that are allocated in the main thread's memory may get destroyed before the
detached thread is destroyed.

If you are using any code that requires the execution of the global
destruction phase for clean up (e.g., removing temp files), then do not use
detached threads, but rather join all threads before exiting the program.

=item Perl Bugs and the CPAN Version of L<threads>

Support for threads extends beyond the code in this module (i.e.,
F<threads.pm> and F<threads.xs>), and into the Perl interpreter itself.  Older
versions of Perl contain bugs that may manifest themselves despite using the
latest version of L<threads> from CPAN.  There is no workaround for this other
than upgrading to the latest version of Perl.

Even with the latest version of Perl, it is known that certain constructs
with threads may result in warning messages concerning leaked scalars or
unreferenced scalars.  However, such warnings are harmless, and may safely be
ignored.

You can search for L<threads> related bug reports at
L<http://rt.cpan.org/Public/>.  If needed submit any new bugs, problems,
patches, etc. to: L<http://rt.cpan.org/Public/Dist/Display.html?Name=threads>

=back

=head1 REQUIREMENTS

Perl 5.8.0 or later

=head1 SEE ALSO