[ViewVC] Diff of: cvs/Coro/Coro.pm

Comparing Coro/Coro.pm (file contents):
Revision 1.202 by root, Tue Sep 30 17:12:34 2008 UTC vs.
Revision 1.214 by root, Tue Nov 11 03:30:21 2008 UTC

 =cut
 package Coro;
-use strict;
+use strict qw(vars subs);
 no warnings "uninitialized";
 use Coro::State;
 use base qw(Coro::State Exporter);
 our $idle;    # idle handler
 our $main;    # main coroutine
 our $current; # current coroutine
-our $VERSION = 4.8;
+our $VERSION = 4.911;
 our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub);
 our %EXPORT_TAGS = (
       prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
 );
    $self->_destroy
       or return;
    # call all destruction callbacks
    $_->(@{$self->{_status}})
-      for @{(delete $self->{_on_destroy}) || []};
+      for @{ delete $self->{_on_destroy} || [] };
 }
 # this coroutine is necessary because a coroutine
 # cannot destroy itself.
 my @destroy;
          while @destroy;
       &schedule;
    }
 };
-$manager->desc ("[coro manager]");
+$manager->{desc} = "[coro manager]";
 $manager->prio (PRIO_MAX);
 =back
 =head2 SIMPLE COROUTINE CREATION
 terminate or join on it (although you are allowed to), and you get a
 coroutine that might have executed other code already (which can be good
 or bad :).
 On the plus side, this function is faster than creating (and destroying)
-a completely new coroutine, so if you need a lot of generic coroutines in
+a completly new coroutine, so if you need a lot of generic coroutines in
 quick successsion, use C<async_pool>, not C<async>.
 The code block is executed in an C<eval> context and a warning will be
 issued in case of an exception instead of terminating the program, as
 C<async> does. As the coroutine is being reused, stuff like C<on_destroy>
 The priority will be reset to C<0> after each run, tracing will be
 disabled, the description will be reset and the default output filehandle
 gets restored, so you can change all these. Otherwise the coroutine will
 be re-used "as-is": most notably if you change other per-coroutine global
-stuff such as C<$/> you I<must needs> to revert that change, which is most
+stuff such as C<$/> you I<must needs> revert that change, which is most
-simply done by using local as in: C< local $/ >.
+simply done by using local as in: C<< local $/ >>.
-The pool size is limited to C<8> idle coroutines (this can be adjusted by
+The idle pool size is limited to C<8> idle coroutines (this can be
-changing $Coro::POOL_SIZE), and there can be as many non-idle coros as
+adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle
-required.
+coros as required.
 If you are concerned about pooled coroutines growing a lot because a
 single C<async_pool> used a lot of stackspace you can e.g. C<async_pool
 { terminate }> once per second or so to slowly replenish the pool. In
 addition to that, when the stacks used by a handler grows larger than 16kb
    } else {
       $self->_cancel;
    }
 }
+=item $coroutine->throw ([$scalar])
+If C<$throw> is specified and defined, it will be thrown as an exception
+inside the coroutine at the next convenient point in time (usually after
+it gains control at the next schedule/transfer/cede). Otherwise clears the
+exception object.
+The exception object will be thrown "as is" with the specified scalar in
+C<$@>, i.e. if it is a string, no line number or newline will be appended
+(unlike with C<die>).
+This can be used as a softer means than C<cancel> to ask a coroutine to
+end itself, although there is no guarantee that the exception will lead to
+termination, and if the exception isn't caught it might well end the whole
+program.
+You might also think of C<throw> as being the moral equivalent of
+C<kill>ing a coroutine with a signal (in this case, a scalar).
 =item $coroutine->join
 Wait until the coroutine terminates and return any values given to the
 C<terminate> or C<cancel> functions. C<join> can be called concurrently
 from multiple coroutines, and all will be resumed and given the status
 higher values mean lower priority, just as in unix).
 =item $olddesc = $coroutine->desc ($newdesc)
 Sets (or gets in case the argument is missing) the description for this
-coroutine. This is just a free-form string you can associate with a coroutine.
+coroutine. This is just a free-form string you can associate with a
+coroutine.
-This method simply sets the C<< $coroutine->{desc} >> member to the given string. You
+This method simply sets the C<< $coroutine->{desc} >> member to the given
-can modify this member directly if you wish.
+string. You can modify this member directly if you wish.
-=item $coroutine->throw ([$scalar])
-If C<$throw> is specified and defined, it will be thrown as an exception
-inside the coroutine at the next convinient point in time (usually after
-it gains control at the next schedule/transfer/cede). Otherwise clears the
-exception object.
-The exception object will be thrown "as is" with the specified scalar in
-C<$@>, i.e. if it is a string, no line number or newline will be appended
-(unlike with C<die>).
-This can be used as a softer means than C<cancel> to ask a coroutine to
-end itself, although there is no guarentee that the exception will lead to
-termination, and if the exception isn't caught it might well end the whole
-program.
 =cut
 sub desc {
    my $old = $_[0]{desc};
          cede; # for short-lived callbacks, this reduces pressure on the coro pool
       }
       schedule; # sleep well
    }
 };
-$unblock_scheduler->desc ("[unblock_sub scheduler]");
+$unblock_scheduler->{desc} = "[unblock_sub scheduler]";
 sub unblock_sub(&) {
    my $cb = shift;
    sub {

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing Coro/Coro.pm (file contents): Revision 1.202 by root, Tue Sep 30 17:12:34 2008 UTC vs. Revision 1.214 by root, Tue Nov 11 03:30:21 2008 UTC

Diff Legend

Comparing Coro/Coro.pm (file contents):
Revision 1.202 by root, Tue Sep 30 17:12:34 2008 UTC vs.
Revision 1.214 by root, Tue Nov 11 03:30:21 2008 UTC