--- Coro/Coro.pm 2007/04/13 12:56:55 1.121 +++ Coro/Coro.pm 2007/09/27 15:52:30 1.139 @@ -22,8 +22,8 @@ This module collection manages coroutines. Coroutines are similar to threads but don't run in parallel at the same time even on SMP -machines. The specific flavor of coroutine use din this module also -guarentees you that it will not switch between coroutines unless +machines. The specific flavor of coroutine used in this module also +guarantees you that it will not switch between coroutines unless necessary, at easily-identified points in your program, so locking and parallel access are rarely an issue, making coroutine programming much safer than threads programming. @@ -52,7 +52,7 @@ our $main; # main coroutine our $current; # current coroutine -our $VERSION = '3.56'; +our $VERSION = '3.8'; our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); our %EXPORT_TAGS = ( @@ -110,11 +110,13 @@ is C<$main> (of course). This variable is B I. It is provided for performance -reasons. If performance is not essentiel you are encouraged to use the +reasons. If performance is not essential you are encouraged to use the C function instead. =cut +$main->{desc} = "[main::]"; + # maybe some other module used Coro::Specific before... $main->{specific} = $current->{specific} if $current; @@ -155,6 +157,14 @@ for @{(delete $self->{destroy_cb}) || []}; } +sub _do_trace_sub { + &{$current->{_trace_sub_cb}} +} + +sub _do_trace_line { + &{$current->{_trace_line_cb}} +} + # this coroutine is necessary because a coroutine # cannot destroy itself. my @destroy; @@ -168,7 +178,7 @@ &schedule; } }; - +$manager->desc ("[coro manager]"); $manager->prio (PRIO_MAX); # static methods. not really. @@ -187,12 +197,9 @@ (usually unused). When the sub returns the new coroutine is automatically terminated. -Calling C in a coroutine will try to do the same as calling exit -outside the coroutine, but this is experimental. It is best not to rely on -exit doing any cleanups or even not crashing. - -When the coroutine dies, the program will exit, just as in the main -program. +Calling C in a coroutine will do the same as calling exit outside +the coroutine. Likewise, when the coroutine dies, the program will exit, +just as it would in the main program. # create a new coroutine that just prints its arguments async { @@ -227,34 +234,38 @@ required. If you are concerned about pooled coroutines growing a lot because a -single C used a lot of stackspace you can e.g. C once per second or so to slowly replenish the pool. +single C used a lot of stackspace you can e.g. C 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 +(adjustable with $Coro::POOL_RSS) it will also exit. =cut our $POOL_SIZE = 8; -our @pool; +our $POOL_RSS = 16 * 1024; +our @async_pool; sub pool_handler { + my $cb; + while () { eval { - my ($cb, @arg) = @{ delete $current->{_invoke} or return }; - $cb->(@arg); + while () { + _pool_1 $cb; + &$cb; + _pool_2 $cb; + &schedule; + } }; - warn $@ if $@; - - last if @pool >= $POOL_SIZE; - push @pool, $current; - $current->save (Coro::State::SAVE_DEF); - $current->prio (0); - schedule; + last if $@ eq "\3terminate\2\n"; + warn $@ if $@; } } sub async_pool(&@) { # this is also inlined into the unlock_scheduler - my $coro = (pop @pool or new Coro \&pool_handler); + my $coro = (pop @async_pool) || new Coro \&pool_handler; $coro->{_invoke} = [@_]; $coro->ready; @@ -282,7 +293,7 @@ undef $current; }; - # call schedule until event occured. + # call schedule until event occurred. # in case we are woken up for other reasons # (current still defined), loop. Coro::schedule while $current; @@ -463,7 +474,7 @@ =item Coro::nready Returns the number of coroutines that are currently in the ready state, -i.e. that can be swicthed to. The value C<0> means that the only runnable +i.e. that can be switched to. The value C<0> means that the only runnable coroutine is the currently running one, so C would have no effect, and C would cause a deadlock unless there is an idle handler that wakes up some coroutines. @@ -509,7 +520,7 @@ immediately without blocking, returning nothing, while the original code ref will be called (with parameters) from within its own coroutine. -The reason this fucntion exists is that many event libraries (such as the +The reason this function exists is that many event libraries (such as the venerable L module) are not coroutine-safe (a weaker form of thread-safety). This means you must not block within event callbacks, otherwise you might suffer from crashes or worse. @@ -530,11 +541,11 @@ # to reduce pressure on the coro pool (because most callbacks # return immediately and can be reused) and because we cannot cede # inside an event callback. -our $unblock_scheduler = async { +our $unblock_scheduler = new Coro sub { while () { while (my $cb = pop @unblock_queue) { # this is an inlined copy of async_pool - my $coro = (pop @pool or new Coro \&pool_handler); + my $coro = (pop @async_pool) || new Coro \&pool_handler; $coro->{_invoke} = $cb; $coro->ready; @@ -543,6 +554,7 @@ schedule; # sleep well } }; +$unblock_scheduler->desc ("[unblock_sub scheduler]"); sub unblock_sub(&) { my $cb = shift; @@ -565,7 +577,7 @@ destruction. very bad things might happen otherwise (usually segfaults). - this module is not thread-safe. You should only ever use this module - from the same thread (this requirement might be losened in the future + from the same thread (this requirement might be loosened in the future to allow per-thread schedulers, but Coro::State does not yet allow this).