Coro
view release on metacpan or search on metacpan
- add ($) prototypes to all functions in Coro::Storable.
- use a conventional (safer) idle callback in Coro::EV.
- do accept quickly in Coro::Debug to avoid endless loops.
4.22 Fri Nov 30 16:04:04 CET 2007
- really use optimised versions for Event and EV in Coro::Util
and Coro::Handle.
4.21 Sun Nov 25 10:48:59 CET 2007
- fix a spurious memory read.
- Coro::EV no longer keeps the eventloop "alive".
4.2 Fri Nov 9 20:47:05 CET 2007
- enable/disable tracing from a new coroutine, not a pooled one.
- fix a memleak in Coro::Event.
- removed killall call from fork_eval.
- made sure store_fd is already loaded so that fork_eval
does not have to parse autoload in each subprocess.
- only use assembly method if -O switch is in $Config{optimize}.
- add (optional) Coro::EV module, so far the best event loop module
directly supported by Coro.
4.03 Sat Oct 6 21:24:00 CEST 2007
- added Coro::throw method.
- minor code cleanups.
4.02 Sat Oct 6 02:36:47 CEST 2007
- fix a very minor per-coroutine memleak (a single codereference).
- fixed a bug where the currently in-use c context would be freed
prematurely (can happen only when programs change the stacksize
or use tracing).
- tracing can no longer keep a coro alive after it terminated.
- do static branch prediction in the common path for gcc. gives
about 2-5% speed improvement here.
4.01 Fri Oct 5 22:10:49 CEST 2007
- instead of recreating *a* standard output handle we simply
use STDOUT, which is faster and hopefully more robust.
4.0 Fri Oct 5 12:56:00 CEST 2007
- incompatibly changed Coro::Storable::freeze.
- major new feature: added Coro::Debug, for interactive coroutine
nor did it deliver partial lines on EOF or error.
- implement malloc fallback for stack allocation because
stupid broken idiotic OSX has a stupid broken
idiotic fits-the-whole-os mmap "implementation" and
my dick feels longer if Coro is portable even to
obsolete platforms.
3.4 Fri Jan 19 21:52:54 CET 2007
- remove t/09_timer.t, as it isn't really testing much
but was rather flaky in practise.
- async_pool coro would keep arguments and callback alive until
it was reused.
- cancellation of a coroutine could cause spurious idle calls
in cede_notself.
3.3 Sat Jan 6 03:45:00 CET 2007
- implement $coro->on_destroy.
- Coro::Event blocking semantics have been changed,
documented and - hopefully - improved.
- fix nice adding, not subtracting, from priority.
- fix ->prio and api_is_ready (patch by Mark Hinds).
async {
print $_[1]; # prints 2
} 1, 2, 3;
This creates a new coro thread and puts it into the ready queue, meaning
it will run as soon as the CPU is free for it.
C<async> will return a Coro object - you can store this for future
reference or ignore it - a thread that is running, ready to run or waiting
for some event is alive on it's own.
Another way to create a thread is to call the C<new> constructor with a
code-reference:
new Coro sub {
# thread code goes here
}, @optional_arguments;
This is quite similar to calling C<async>, but the important difference is
that the new thread is not put into the ready queue, so the thread will
Suspends the specified coro. A suspended coro works just like any other
coro, except that the scheduler will not select a suspended coro for
execution.
Suspending a coro can be useful when you want to keep the coro from
running, but you don't want to destroy it, or when you want to temporarily
freeze a coro (e.g. for debugging) to resume it later.
A scenario for the former would be to suspend all (other) coros after a
fork and keep them alive, so their destructors aren't called, but new
coros can be created.
=item $coro->resume
If the specified coro was suspended, it will be resumed. Note that when
the coro was in the ready queue when it was suspended, it might have been
unreadied by the scheduler, so an activation might have been lost.
To avoid this, it is best to put a suspended coro into the ready queue
unconditionally, as every synchronisation mechanism must protect itself
async {
print $_[1]; # prints 2
} 1, 2, 3;
This creates a new coro thread and puts it into the ready queue,
meaning it will run as soon as the CPU is free for it.
"async" will return a Coro object - you can store this for future
reference or ignore it - a thread that is running, ready to run or
waiting for some event is alive on it's own.
Another way to create a thread is to call the "new" constructor with
a code-reference:
new Coro sub {
# thread code goes here
}, @optional_arguments;
This is quite similar to calling "async", but the important
difference is that the new thread is not put into the ready queue,
$coro->suspend
Suspends the specified coro. A suspended coro works just like any
other coro, except that the scheduler will not select a suspended
coro for execution.
Suspending a coro can be useful when you want to keep the coro from
running, but you don't want to destroy it, or when you want to
temporarily freeze a coro (e.g. for debugging) to resume it later.
A scenario for the former would be to suspend all (other) coros
after a fork and keep them alive, so their destructors aren't
called, but new coros can be created.
$coro->resume
If the specified coro was suspended, it will be resumed. Note that
when the coro was in the ready queue when it was suspended, it might
have been unreadied by the scheduler, so an activation might have
been lost.
To avoid this, it is best to put a suspended coro into the ready
queue unconditionally, as every synchronisation mechanism must
( run in 1.293 second using v1.01-cache-2.11-cpan-39bf76dae61 )