use strict;
use warnings;
-our $VERSION = '1.04';
+our $VERSION = '1.07';
my $XS_VERSION = $VERSION;
$VERSION = eval $VERSION;
=head1 VERSION
-This document describes threads::shared version 1.04
+This document describes threads::shared version 1.07
=head1 SYNOPSIS
C<lock> places a lock on a variable until the lock goes out of scope. If the
variable is locked by another thread, the C<lock> call will block until it's
-available. C<lock> is recursive, so multiple calls to C<lock> are safe -- the
-variable will remain locked until the outermost lock on the variable goes out
-of scope.
+available. Multiple calls to C<lock> by the same thread from within
+dynamically nested scopes are safe -- the variable will remain locked until
+the outermost lock on the variable goes out of scope.
-If a container object, such as a hash or array, is locked, all the elements of
-that container are not locked. For example, if a thread does a C<lock @a>,
-any other thread doing a C<lock($a[12])> won't block.
+Locking a container object, such as a hash or array, doesn't lock the elements
+of that container. For example, if a thread does a C<lock(@a)>, any other
+thread doing a C<lock($a[12])> won't block.
-C<lock> will traverse up references exactly I<one> level. C<lock(\$a)> is
-equivalent to C<lock($a)>, while C<lock(\\$a)> is not.
+C<lock()> follows references exactly I<one> level. C<lock(\$a)> is equivalent
+to C<lock($a)>, while C<lock(\\$a)> is not.
Note that you cannot explicitly unlock a variable; you can only wait for the
lock to go out of scope. This is most easily accomplished by locking the
C<cond_signal> will normally generate a warning if you attempt to use it on an
unlocked variable. On the rare occasions where doing this may be sensible, you
-can skip the warning with:
+can suppress the warning with:
{ no warnings 'threads'; cond_signal($foo); }
=head1 OBJECTS
L<threads::shared> exports a version of L<bless()|perlfunc/"bless REF"> that
-works on shared objects such that i<blessings> propagate across threads.
+works on shared objects such that I<blessings> propagate across threads.
# Create a shared 'foo' object
my $foo;
and scalar refs are not affected by this problem.)
It is often not wise to share an object unless the class itself has been
-written to support sharing. For example, an object's destructor may get called
-multiple times, one for each thread's scope exit. Another example, is that
-the contents of hash-based objects will be lost due to the above mentioned
-limitation. See F<examples/class.pl> (in the CPAN distribution of this
-module) for how to create a class that supports object sharing.
+written to support sharing. For example, an object's destructor may get
+called multiple times, once for each thread's scope exit. Another danger is
+that the contents of hash-based objects will be lost due to the above
+mentioned limitation. See F<examples/class.pl> (in the CPAN distribution of
+this module) for how to create a class that supports object sharing.
Does not support C<splice> on arrays!
L<http://www.cpanforum.com/dist/threads-shared>
Annotated POD for L<threads::shared>:
-L<http://annocpan.org/~JDHEDDEN/threads-shared-1.04/shared.pm>
+L<http://annocpan.org/~JDHEDDEN/threads-shared-1.07/shared.pm>
L<threads>, L<perlthrtut>