Result:
found 469 distributions and 1050 files matching your query !
( run in 0.527 )
Compress-LZF
view release on metacpan or search on metacpan
perlmulticore.h view on Meta::CPAN
Of course, the overhead is much higher when these functions actually
implement anything useful, but you always get what you pay for.
With L<Coro::Multicore>, every release/acquire involves two pthread
switches, two coro thread switches, a bunch of syscalls, and sometimes
interacting with the event loop.
A dedicated thread pool such as the one L<IO::AIO> uses could reduce
these overheads, and would also reduce the dependencies (L<AnyEvent> is a
smaller and more portable dependency than L<Coro>), but it would require a
Compress-PPMd
view release on metacpan or search on metacpan
t/1_quijote.t view on Meta::CPAN
necesario, así para el aumento de su honra como para el servicio de su
república, hacerse caballero andante, y irse por todo el mundo con sus
armas y caballo a buscar las aventuras y a ejercitarse en todo aquello que
él había leído que los caballeros andantes se ejercitaban, deshaciendo todo
género de agravio, y poniéndose en ocasiones y peligros donde, acabándolos,
cobrase eterno nombre y fama. Imaginábase el pobre ya coronado por el valor
de su brazo, por lo menos, del imperio de Trapisonda; y así, con estos tan
agradables pensamientos, llevado del estraño gusto que en ellos sentía, se
dio priesa a poner en efeto lo que deseaba.
Y lo primero que hizo fue limpiar unas armas que habían sido de sus
Continuity-Widget
view release on metacpan or search on metacpan
lib/Continuity/Coro/Continuation.pm view on Meta::CPAN
our @yieldstack;
sub continuation (&) {
my $code = shift;
my $prev = new Coro::State;
my $coro = Coro::State->new(sub {
yield();
$code->();
});
push @yieldstack, [$coro, $prev];
$prev->transfer($coro);
return sub {
push @yieldstack, [$coro, $prev, @_];
$prev->transfer($coro);
};
}
sub yield {
my ($coro, $prev) = @{pop @yieldstack};
$coro->transfer($prev);
}
1;
Continuity
view release on metacpan or search on metacpan
eg/slowprint.pl view on Meta::CPAN
use lib '../lib';
use Continuity;
use Coro::AnyEvent;
use Coro::Debug;
our $coro_debug_server = new_unix_server Coro::Debug "/tmp/corodebug";
$| = 1;
my $reap_watcher;
sub reaper {
Convert-Pheno
view release on metacpan or search on metacpan
share/db/concepts_candidates_2_exposure.csv view on Meta::CPAN
4138217 Seen by social services department occupational therapist Observation SNOMED Clinical Finding S "305775001" 2002-01-31 2099-12-31
4138351 Seen by occupational therapy service Observation SNOMED Clinical Finding S "305852001" 2002-01-31 2099-12-31
46285972 Education on provision of occupational skills training to service user Observation SNOMED Context-dependent S "979391000000102" 2015-10-01 2099-12-31
4263813 Chemotherapy AND/OR radiation therapy prior to lymphadenectomy Observation SNOMED Context-dependent S "396780003" 2003-07-31 2099-12-31
4287023 No chemotherapy AND/OR radiation therapy prior to lymphadenectomy Observation SNOMED Context-dependent S "396781004" 2003-07-31 2099-12-31
756049 History of Suspected exposure (but ruled out after evaluation) to Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) in the 14 days prior to illness onset Observation OMOP Extension Context-dependent S OMOP4873925 2020-03-18 2099-12-...
756063 History of Animal exposure in the 14 days prior to illness onset Observation OMOP Extension Context-dependent S OMOP4873939 2020-03-18 2099-12-31
756040 History of Close exposure to Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) in the 14 days prior to illness onset Observation OMOP Extension Context-dependent S OMOP4873943 2020-03-18 2099-12-31
756048 History of Suspected exposure to Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) in the 14 days prior to illness onset Observation OMOP Extension Context-dependent S OMOP4873923 2020-03-18 2099-12-31
762538 Mother receiving radiation therapy Observation SNOMED Context-dependent S "428641000124103" 2012-09-01 2099-12-31
4079773 Patient advised about exposure to the sun Observation SNOMED Context-dependent S "183079004" 2002-01-31 2099-12-31
4327716 Family history of radiation therapy Observation SNOMED Context-dependent S "430786004" 2008-07-31 2099-12-31
35609834 Daily HIV-PrEP (human immunodeficiency virus pre-exposure prophylaxis) commenced Observation SNOMED Context-dependent S "1086581000000100" 2017-10-01 2099-12-31
35609835 Event-based HIV-PrEP (human immunodeficiency virus pre-exposure prophylaxis) commenced Observation SNOMED Context-dependent S "1086591000000103" 2017-10-01 2099-12-31
share/db/concepts_candidates_2_exposure.csv view on Meta::CPAN
4320003 Overexposure to gamma rays Observation SNOMED Event S "218204007" 2002-01-31 2099-12-31
4320004 Overexposure to hard X-rays Observation SNOMED Event S "218205008" 2002-01-31 2099-12-31
4320005 Overexposure to soft X-rays Observation SNOMED Event S "218206009" 2002-01-31 2099-12-31
4320027 Exposure to extreme temperature, non-occupational Observation SNOMED Event S "95866005" 2002-01-31 2099-12-31
35622979 Occupational exposure to extreme temperature Observation SNOMED Event S "765226004" 2018-07-31 2099-12-31
37310260 Close exposure to SARS-CoV-2 (severe acute respiratory syndrome coronavirus 2) infection Observation SNOMED Event S "1240441000000108" 2020-02-04 2099-12-31
42535209 Occupational exposure to radiation Observation SNOMED Event S "16090451000119101" 2018-01-31 2099-12-31
42535211 Occupational exposure to toxic agents Observation SNOMED Event S "16090571000119109" 2018-01-31 2099-12-31
42535212 Occupational exposure to risk factor Observation SNOMED Event S "16090731000119102" 2018-01-31 2099-12-31
42535213 Occupational exposure to environmental tobacco smoke Observation SNOMED Event S "16090771000119104" 2018-01-31 2099-12-31
42536905 Occupational exposure to vibration Observation SNOMED Event S "735932007" 2018-01-31 2099-12-31
share/db/concepts_candidates_2_exposure.csv view on Meta::CPAN
442042 Exposure to radiation from diagnostic isotopes Observation SNOMED Event S "242811002" 2002-01-31 2099-12-31
443065 Accidental exposure to metals or their compounds Observation SNOMED Event S "242373001" 2002-01-31 2099-12-31
444046 Cold exposure Observation SNOMED Event S "40537000" 2002-01-31 2099-12-31
444128 Exposure to ionizing radiation Observation SNOMED Event S "122866006" 2002-01-31 2099-12-31
604443 Occupational exposure to SARS-CoV-2 Observation SNOMED Event S "897036007" 2021-01-31 2099-12-31
756064 Suspected exposure (but ruled out after evaluation) to Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) Observation OMOP Extension Event S OMOP4873946 2020-03-18 2099-12-31
756083 Suspected exposure to Severe acute respiratory syndrome coronavirus 2 (SARS-CoV-2) Observation OMOP Extension Event S OMOP4873962 2020-03-18 2099-12-31
4008044 Exposure to polluted water, occupational Observation SNOMED Event S "102428006" 2002-01-31 2099-12-31
4008045 Exposure to polluted water, non-occupational Observation SNOMED Event S "102429003" 2002-01-31 2099-12-31
4008150 Exposure to toxic waste, occupational Observation SNOMED Event S "102439009" 2002-01-31 2099-12-31
4008152 Exposure to toxic dust, non-occupational Observation SNOMED Event S "102446000" 2002-01-31 2099-12-31
4009857 Exposure to environmental pollution, non-occupational Observation SNOMED Event S "102423002" 2002-01-31 2099-12-31
Convert-TBX-UTX
view release on metacpan or search on metacpan
t/Corpus/Sample.utx view on Meta::CPAN
acute bacterial endocarditis 急性細èŒæ€§å¿ƒå†…膜症 noun
acute bronchitis 急性気管支炎 noun
acute chorea 急性舞è¸ç—‡ noun
acute compliance 早期コンプライアンス noun
acute conjunctivitis 急性çµè†œç‚Ž noun
acute coronary occlusion æ€¥æ€§å† é–‰å¡ž noun
acute disease 急性疾患 noun
acute eczema 急性湿疹 noun
acute endocarditis 急性心内膜炎 noun
acute exacerbation 急性増悪 noun
acute exanthema 急性発疹 noun
Cookie
view release on metacpan or search on metacpan
lib/Cookie/public_suffix_list.txt view on Meta::CPAN
// sandvik : Sandvik AB
// https://www.iana.org/domains/root/db/sandvik.html
sandvik
// sandvikcoromant : Sandvik AB
// https://www.iana.org/domains/root/db/sandvikcoromant.html
sandvikcoromant
// sanofi : Sanofi
// https://www.iana.org/domains/root/db/sanofi.html
sanofi
Coro-Amazon-SimpleDB
view release on metacpan or search on metacpan
lib/Coro/Amazon/SimpleDB.pm view on Meta::CPAN
# The only mention of a time-out in Amazon::SimpleDB::Client is in
# reference to a select operation. I'm using the value from there
# (5 seconds) as the default time-out for HTTP requests, as it
# seems reasonable. The setting is dynamic, but is used prior to
# putting HTTP request coros into wait state so it should do the
# expected thing if it's changed. Caveat emptor.
our $HTTP_REQUEST_TIMEOUT = 5;
# Replace the _httpPost method in Amazon::SimpleDB::Client to use
lib/Coro/Amazon/SimpleDB.pm view on Meta::CPAN
$response = HTTP::Response->new(@{$headers}{qw( Status Reason )});
$response->content($body);
$response->header($_, $headers->{$_})
for grep { !/[[:upper:]]/ } keys %{$headers};
};
# We need to put this coro to sleep until the response is returned.
while (not defined $response) { Coro::AnyEvent::sleep 0.1 }
return $response;
}
}
lib/Coro/Amazon/SimpleDB.pm view on Meta::CPAN
$start = time() if $debug;
for ($[ .. $#requests) {
my $idx = $_;
my $request = $requests[$idx];
$self->bug("adding request $request");
my $coro = async {
my ($start, $duration) = (0, 0);
$self->bug("starting request for $request");
$start = time() if $debug;
$responses[$idx] = eval { $self->_process_request($request) };
# Store the exception instead of the response (which
# should be undef) if there was a problem.
$responses[$idx] = $@ if $@;
$duration = time() - $start if $debug;
$self->bug("completed request for $request in $duration secs");
};
$self->add_pending($coro);
$coro->on_destroy(sub { $self->remove_pending($coro) });
}
$duration = time() - $start if $debug;
$self->bug("completed async enqueues in $duration secs, starting coro polling");
$self->poll;
return \@responses;
}
lib/Coro/Amazon/SimpleDB.pm view on Meta::CPAN
This is automatically created when first requested, but may also be
passed in manually.
=head2 pending
A hash ref of pending coros. This is used internally to poll for
completion of all asynchronous requests.
=head2 DEBUG
If set to a true value, the library will output some debugging and
lib/Coro/Amazon/SimpleDB.pm view on Meta::CPAN
Dave Trischuk, C<< <dtrischuk at cpan.org> >>
=head1 BUGS
Please report any bugs or feature requests to C<bug-coro-amazon-simpledb at rt.cpan.org>, or through
the web interface at L<http://rt.cpan.org/NoAuth/ReportBug.html?Queue=Coro-Amazon-SimpleDB>. I will be notified, and then you'll
automatically be notified of progress on your bug as I make changes.
=head1 SUPPORT
Coro-DataPipe
view release on metacpan or search on metacpan
lib/Coro/DataPipe.pm view on Meta::CPAN
my $main = $Coro::current;
$self->{process_iterator} = sub {
my $data = shift;
my $item_number = $self->{item_number}++;
$self->{busy}++;
my $coro = async {
local $_ = $data;
$_ = $process_data_callback->($data);
$self->{output_iterator}->($_,$item_number);
$self->{busy}--;
$main->ready;
Coro-Generator
view release on metacpan or search on metacpan
lib/Coro/Generator.pm view on Meta::CPAN
our @params;
sub generator (&) {
my $code = shift;
my $prev = new Coro::State;
my $coro = Coro::State->new(sub {
yield();
$code->(@params) while 1;
});
push @yieldstack, [$coro, $prev];
$prev->transfer($coro);
return sub {
@params = @_;
push @yieldstack, [$coro, $prev];
$prev->transfer($coro);
return $retval;
};
}
sub yield {
$retval = shift;
my ($coro, $prev) = @{pop @yieldstack};
$coro->transfer($prev);
return wantarray ? @params : $params[0];
}
=head1 SEE ALSO
Coro-LocalScalar-XS
view release on metacpan or search on metacpan
$Coro::LocalScalar::XS = '0.2';
DynaLoader::bootstrap Coro::LocalScalar::XS $Coro::LocalScalar::XS;
=head1 NAME
Coro::LocalScalar::XS - Different scalar values in coroutines
=head1 ABOUT
This is optimized XS version of L<Coro::LocalScalar>. It's almost two times faster and has simplier api - only one function.
This module destroys all local data(and DESTROYs are called) when coroutine get destroyed. This is useful for example if you want to have global variable $request with different object in each coro.
Coro::LocalScalar::XS keeps reference to localized variable, so localize only variables, that will persist all execution time. Localizing hundreds of variables is also bad idea, because each variable adds little overhead when each coro is destroyed
=head1 SYNOPSIS
use Coro;
use Coro::EV;
my $scalar;
use Coro::LocalScalar::XS;
localize($scalar); # $scalar is now different in all coros. Current value of $scalar is deleted.
# $hash{element} = undef; # hash element MUST exist if you want to localize it correctly
# localize($hash{element});
# localizing arrays or hashes unsupported, use refs
=cut
sub _set_ondestroy_cb {
my $coro = $Coro::current;
$coro->on_destroy(sub {
# when i use magick to store local copy of var for each coroutine the current value is stored in localized scalar itself
# sv_setsv(sv, &PL_sv_undef ); from XS has no effect and value is still stored in scalar
# so if value in scalar is object, then when coroutine gets destroyed Coro::LocalScalar::XS destroys it's internal storage,
# but one reference persists in scalar itself and object destructor will not be called till scalar will be reassigned
Coro::LocalScalar::XS::cleanup($coro); # clean internal storage and disable magick
$$_ = undef for @Coro::LocalScalar::XS::localized; # reassign all localized scalar to call destructors
Coro::LocalScalar::XS::reenable_magick(); # enable magick
$coro = undef ;
});
undef;
}
Coro-LocalScalar
view release on metacpan or search on metacpan
LocalScalar.pm view on Meta::CPAN
Coro::LocalScalar - local() for Coro
=head1 ABOUT
Perl local() function unuseful for Coro threads. This module uses tie magick to make scalar local for each Coro thread. Unlike L<Coro::Specific> this module destroys all data attached to coroutine when coroutine gets destroyed. It's useful when you n...
=head1 SYNOPSIS
use Coro;
use Coro::LocalScalar;
LocalScalar.pm view on Meta::CPAN
my $testobj = Someclass->new;
# attach setter/getter and tied hash element to your object
$obj->attach($testobj, 'element_local_in_coros');
$testobj->element_local_in_coros("data");
$testobj->element_local_in_coros = "data";
$testobj->{element_local_in_coros}; # tie magick used
=cut
LocalScalar.pm view on Meta::CPAN
sub _proto : lvalue {
my $self = shift;
unless(exists($self->{$Coro::current})){
my $coro = $Coro::current;
$self->{$coro} = undef;
# init coro data destructor
$coro->on_destroy(sub {
${ $self->{scalar} } = undef; # Delete scalar value to prevent unexpected behavior
#perl stores values in scalar even if it tied. When Coro::LocalScalar destroys internal value, value stored in scalar still persists although you expected that it would be deleted( and DESTROY called if it`s object)
delete $self->{$coro};
undef $coro;
});
};
if(@_){ $self->{$Coro::current} = shift }
Coro-Localize
view release on metacpan or search on metacpan
lib/Coro/Localize.pm view on Meta::CPAN
# ABSTRACT: Localize variables to a coroutine
package Coro::Localize;
{
$Coro::Localize::VERSION = '0.1.2';
}
use common::sense;
lib/Coro/Localize.pm view on Meta::CPAN
my $stub = sub {};
sub import_into {
my $class = shift;
my( $target ) = @_;
Devel::Declare->setup_for( $target => { corolocal => {const => \&parser} } );
*{$target.'::corolocal'} = $stub;
}
our $prefix = '';
sub get {substr Devel::Declare::get_linestr, length $prefix}
sub set { Devel::Declare::set_linestr $prefix . $_[0]}
lib/Coro/Localize.pm view on Meta::CPAN
set substr get, $skip;
}
sub strip_keyword {
strip_space;
get =~ /^(corolocal)(?:\b|$)/ or croak "Could not match corolocal", get;
$prefix .= $1;
return $1;
}
sub strip_comma {
lib/Coro/Localize.pm view on Meta::CPAN
=encoding utf-8
=head1 NAME
Coro::Localize - Localize variables to a coroutine
=head1 VERSION
version 0.1.2
lib/Coro/Localize.pm view on Meta::CPAN
use feature qw( say );
use Coro;
use Coro::EV;
use Coro::Localize;
# Or with Syntax::Feature:
# use syntax qw( corolocal );
our $scalar = "main loop";
async {
corolocal $scalar = "thread 1";
say "# 1 - $scalar";
cede;
say "# 3 - $scalar";
cede;
say "# 5 - $scalar";
};
async {
corolocal $scalar = "thread 2";
say "# 2 - $scalar";
cede;
say "# 4 - $scalar";
cede;
say "# 6 - $scalar";
lib/Coro/Localize.pm view on Meta::CPAN
# 6 - thread 2
# complete main loop
=head1 DESCRIPTION
This provides a new keyword, "corolocal" that works will localize a variable
to a particular coroutine. This allows you to have thread-local values for
global variables. It can localize scalars, arrays and hashes.
=head1 IMPLEMENTATION
It localizes variables by Coro on_enter and on_leave blocks combined with
Data::Alias to fiddle with where the variable points.
corolocal $/ = \2_048;
Is exactly equivalent to:
use Data::Alias;
my(%external_values,%internal_values);
Coro-MP
view release on metacpan or search on metacpan
our @EXPORT = (@AnyEvent::MP::EXPORT, qw(
port_async rcv_async get get_cond syncal peval_async
));
our @EXPORT_OK = (@AnyEvent::MP::EXPORT_OK);
sub _new_coro {
my ($port, $threadcb) = @_;
my $coro = async_pool {
eval { $threadcb->() };
kil $SELF, die => $@ if $@;
};
$coro->swap_sv (\$SELF, \$port);
# killing the port cancels the coro
# delaying kil messages inside aemp guarantees
# (hopefully) that $coro != $Coro::current.
mon $port, sub { $coro->cancel (@_) };
# cancelling the coro kills the port
$coro->on_destroy (sub { kil $port, @_ });
$coro
}
=item NODE, $NODE, node_of, configure
=item $SELF, *SELF, SELF, %SELF, @SELF...
=cut
sub rcv_async($$) {
my ($port, $threadcb) = @_;
my (@queue, $coro);
AnyEvent::MP::rcv $port, sub {
push @queue, \@_; # TODO, take copy?
$coro->ready; # TODO, maybe too many unwanted wake-ups?
};
$coro = _new_coro $port, $threadcb;
$coro->{_coro_mp_queue} = \@queue;
}
=item @msg = get $tag
=item @msg = get $tag, $timeout
=cut
sub get($;$) {
my ($tag, $timeout) = @_;
my $queue = $Coro::current->{_coro_mp_queue}
or Carp::croak "Coro::MP::get called from thread not attached to any port";
my $i;
while () {
sub _true { 1 }
sub get_cond(;&$) {
my ($cond, $timeout) = @_;
my $queue = $Coro::current->{_coro_mp_queue}
or Carp::croak "Coro::MP::get_cond called from thread not attached to any port";
my ($i, $ok);
$cond ||= \&_true;
};
=cut
sub peval_async($$) {
_new_coro $_[0], $_[1]
}
=item @reply = syncal $port, @msg, $callback[, $timeout]
The synchronous form of C<cal>, a simple form of RPC - it sends a message
Coro-Multicore
view release on metacpan or search on metacpan
Multicore.pm view on Meta::CPAN
=head1 NAME
Coro::Multicore - make coro threads on multiple cores with specially supported modules
=head1 SYNOPSIS
# when you DO control the main event loop, e.g. in the main program
Multicore.pm view on Meta::CPAN
While L<Coro> threads (unlike ithreads) provide real threads similar to
pthreads, python threads and so on, they do not run in parallel to each
other even on machines with multiple CPUs or multiple CPU cores.
This module lifts this restriction under two very specific but useful
conditions: firstly, the coro thread executes in XS code and does not
touch any perl data structures, and secondly, the XS code is specially
prepared to allow this.
This means that, when you call an XS function of a module prepared for it,
this XS function can execute in parallel to any other Coro threads. This
Multicore.pm view on Meta::CPAN
The function returns the previous value of the enable flag.
=item Coro::Multicore::scoped_enable
This function instructs Coro::Multicore to handle all requests executed
in the current coro thread, from the call to the end of the current scope.
Calls to C<scoped_enable> and C<scoped_disable> don't nest very well at
the moment, so don't nest them.
=item Coro::Multicore::scoped_disable
Coro-Mysql
view release on metacpan or search on metacpan
more efficient buffering and allows requests to run in parallel, it often
decreases the actual time to run many queries considerably.
For very fast queries ("select 0"), this module can add noticable overhead
(around 15%, 7% when EV can be used) as it tries to switch to other
coroutines when mysqld doesn't deliver the data immediately, although,
again, when running queries in parallel, they will usually execute faster.
For most types of queries, there will be no extra latency, especially on
multicore systems where your perl process can do other things while mysqld
does its stuff.
Coro-PatchSet
view release on metacpan or search on metacpan
lib/Coro/PatchSet/LWP.pm view on Meta::CPAN
Nowadays LWP may use IO::Socket::INET6 or IO::Socket::IP as socket class instead of IO::Socket::INET.
But Coro::LWP substitutes only IO::Socket::INET. So your LWP may become blocking because will still
use blocking IO::Socket::INET6 or IO::Socket::IP. This patch fixes this. But note, it will not add
IPv6 support for LWP, because Coro::Socket is still IPv4 only. See t/09_lwp_socket_class.t
=head2 coro compatible support for https
Coro::LWP doesn't do any special hacks about https, so https connections still blocks coro threads.
This patch fixes this problem, but don't forget to load it before IO::Socket::SSL, so C<use> it as early as
possible.
=head2 loading other necessary patches
Coro-Twiggy
view release on metacpan or search on metacpan
lib/Coro/Twiggy.pm view on Meta::CPAN
$server->register_service( $application );
=head1 DESCRIPTION
The server starts Your application in L<Coro/async> coroutine and uses its
return value to respond to client.
Application have to return an B<ARRAYREF> with the following items:
=over
lib/Coro/Twiggy.pm view on Meta::CPAN
1;
=head1 VCS
L<https://github.com/unera/coro-twiggy>
=head1 AUTHOR
Dmitry E. Oboukhov, <unera@debian.org>
Coro
view release on metacpan or search on metacpan
print "2\n";
cede; # yield back to main
print "4\n";
};
print "1\n";
cede; # yield to coro
print "3\n";
cede; # and again
# use locking
my $lock = new Coro::Semaphore;
For a tutorial-style introduction, please read the L<Coro::Intro>
manpage. This manpage mainly contains reference information.
This module collection manages continuations in general, most often in
the form of cooperative threads (also called coros, or simply "coro"
in the documentation). They are similar to kernel threads but don't (in
general) run in parallel at the same time even on SMP machines. The
specific flavor of thread offered by this module also guarantees you that
it will not switch between threads unless necessary, at easily-identified
points in your program, so locking and parallel access are rarely an
Unlike the so-called "Perl threads" (which are not actually real threads
but only the windows process emulation (see section of same name for
more details) ported to UNIX, and as such act as processes), Coro
provides a full shared address space, which makes communication between
threads very easy. And coro threads are fast, too: disabling the Windows
process emulation code in your perl and using Coro can easily result in
a two to four times speed increase for your programs. A parallel matrix
multiplication benchmark (very communication-intensive) runs over 300
times faster on a single core than perls pseudo-threads on a quad core
using all four cores.
See also the C<SEE ALSO> section at the end of this document - the Coro
module family is quite large.
=head1 CORO THREAD LIFE CYCLE
During the long and exciting (or not) life of a coro thread, it goes
through a number of states:
=over 4
=item 1. Creation
The first thing in the life of a coro thread is it's creation -
obviously. The typical way to create a thread is to call the C<async
BLOCK> function:
async {
# thread code goes here
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.
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
not run until somebody puts it there. C<async> is, therefore, identical to
this sequence:
my $coro = new Coro sub {
# thread code goes here
};
$coro->ready;
return $coro;
=item 2. Startup
When a new coro thread is created, only a copy of the code reference
and the arguments are stored, no extra memory for stacks and so on is
allocated, keeping the coro thread in a low-memory state.
Only when it actually starts executing will all the resources be finally
allocated.
The optional arguments specified at coro creation are available in C<@_>,
similar to function calls.
=item 3. Running / Blocking
A lot can happen after the coro thread has started running. Quite usually,
it will not run to the end in one go (because you could use a function
instead), but it will give up the CPU regularly because it waits for
external events.
As long as a coro thread runs, its Coro object is available in the global
variable C<$Coro::current>.
The low-level way to give up the CPU is to call the scheduler, which
selects a new coro thread to run:
Coro::schedule;
Since running threads are not in the ready queue, calling the scheduler
without doing anything else will block the coro thread forever - you need
to arrange either for the coro to put woken up (readied) by some other
event or some other thread, or you can put it into the ready queue before
scheduling:
# this is exactly what Coro::cede does
$Coro::current->ready;
All the higher-level synchronisation methods (Coro::Semaphore,
Coro::rouse_*...) are actually implemented via C<< ->ready >> and C<<
Coro::schedule >>.
While the coro thread is running it also might get assigned a C-level
thread, or the C-level thread might be unassigned from it, as the Coro
runtime wishes. A C-level thread needs to be assigned when your perl
thread calls into some C-level function and that function in turn calls
perl and perl then wants to switch coroutines. This happens most often
when you run an event loop and block in the callback, or when perl
itself calls some function such as C<AUTOLOAD> or methods via the C<tie>
mechanism.
=item 4. Termination
Many threads actually terminate after some time. There are a number of
ways to terminate a coro thread, the simplest is returning from the
top-level code reference:
async {
# after returning from here, the coro thread is terminated
};
async {
return if 0.5 < rand; # terminate a little earlier, maybe
print "got a chance to print this\n";
# or here
};
Any values returned from the coroutine can be recovered using C<< ->join
>>:
my $coro = async {
"hello, world\n" # return a string
};
my $hello_world = $coro->join;
print $hello_world;
Another way to terminate is to call C<< Coro::terminate >>, which at any
subroutine call nesting level:
async {
Coro::terminate "return value 1", "return value 2";
};
Yet another way is to C<< ->cancel >> (or C<< ->safe_cancel >>) the coro
thread from another thread:
my $coro = async {
exit 1;
};
$coro->cancel; # also accepts values for ->join to retrieve
Cancellation I<can> be dangerous - it's a bit like calling C<exit> without
actually exiting, and might leave C libraries and XS modules in a weird
state. Unlike other thread implementations, however, Coro is exceptionally
safe with regards to cancellation, as perl will always be in a consistent
state, and for those cases where you want to do truly marvellous things
with your coro while it is being cancelled - that is, make sure all
cleanup code is executed from the thread being cancelled - there is even a
C<< ->safe_cancel >> method.
So, cancelling a thread that runs in an XS event loop might not be the
best idea, but any other combination that deals with perl only (cancelling
when a thread is in a C<tie> method or an C<AUTOLOAD> for example) is
safe.
Last not least, a coro thread object that isn't referenced is C<<
->cancel >>'ed automatically - just like other objects in Perl. This
is not such a common case, however - a running thread is referencedy by
C<$Coro::current>, a thread ready to run is referenced by the ready queue,
a thread waiting on a lock or semaphore is referenced by being in some
wait list and so on. But a thread that isn't in any of those queues gets
cancelled:
async {
schedule; # cede to other coros, don't go into the ready queue
};
cede;
# now the async above is destroyed, as it is not referenced by anything.
# if we return, or die or get cancelled, here,
# then the semaphore will be "up"ed.
};
The C<Guard::guard> function comes in handy for any custom cleanup you
might want to do (but you cannot switch to other coroutines from those
code blocks):
async {
my $window = new Gtk2::Window "toplevel";
# The window will not be cleaned up automatically, even when $window
# we are safe here
};
Last not least, C<local> can often be handy, too, e.g. when temporarily
replacing the coro thread description:
sub myfunction {
local $Coro::current->{desc} = "inside myfunction(@_)";
# if we return or die here, the description will be restored
# run the async above, and free everything before returning
# from Coro::cede:
Coro::cede;
{
my $coro = async {
print "hi\n";
1
};
# run the async above, and clean up, but do not free the coro
# object:
Coro::cede;
# optionally retrieve the result values
my @results = $coro->join;
# now $coro goes out of scope, and presumably gets freed
};
=back
=cut
use Coro::State;
use base qw(Coro::State Exporter);
our $idle; # idle handler
our $main; # main coro
our $current; # current coro
our $VERSION = 6.514;
our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub rouse_cb rouse_wait);
our %EXPORT_TAGS = (
=item $Coro::main
This variable stores the Coro object that represents the main
program. While you can C<ready> it and do most other things you can do to
coro, it is mainly useful to compare again C<$Coro::current>, to see
whether you are running in the main program or not.
=cut
# $main is now being initialised by Coro::State
=item $Coro::current
The Coro object representing the current coro (the last
coro that the Coro scheduler switched to). The initial value is
C<$Coro::main> (of course).
This variable is B<strictly> I<read-only>. You can take copies of the
value stored in it and use it as any other Coro object, but you must
not otherwise modify the variable itself.
The default implementation dies with "FATAL: deadlock detected.", followed
by a thread listing, because the program has no other way to continue.
This hook is overwritten by modules such as C<Coro::EV> and
C<Coro::AnyEvent> to wait on an external event that hopefully wakes up a
coro so the scheduler can run it.
See L<Coro::EV> or L<Coro::AnyEvent> for examples of using this technique.
=cut
require Coro::Debug;
die "FATAL: deadlock detected.\n"
. Coro::Debug::ps_listing ();
};
# this coro is necessary because a coro
# cannot destroy itself.
our @destroy;
our $manager;
$manager = new Coro sub {
while @destroy;
&schedule;
}
};
$manager->{desc} = "[coro manager]";
$manager->prio (PRIO_MAX);
=back
=head1 SIMPLE CORO CREATION
=over 4
=item async { ... } [@args...]
Create a new coro and return its Coro object (usually
unused). The coro will be put into the ready queue, so
it will start running automatically on the next scheduler run.
The first argument is a codeblock/closure that should be executed in the
coro. When it returns argument returns the coro is automatically
terminated.
The remaining arguments are passed as arguments to the closure.
See the C<Coro::State::new> constructor for info about the coro
environment in which coro are executed.
Calling C<exit> in a coro will do the same as calling exit outside
the coro. Likewise, when the coro dies, the program will exit,
just as it would in the main program.
If you do not want that, you can provide a default C<die> handler, or
simply avoid dieing (by use of C<eval>).
Example: Create a new coro that just prints its arguments.
async {
print "@_\n";
} 1,2,3,4;
=item async_pool { ... } [@args...]
Similar to C<async>, but uses a coro pool, so you should not call
terminate or join on it (although you are allowed to), and you get a
coro that might have executed other code already (which can be good
or bad :).
On the plus side, this function is about twice as fast as creating (and
destroying) a completely new coro, so if you need a lot of generic
coros 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 coro is being reused, stuff like C<on_destroy>
will not work in the expected way, unless you call terminate or cancel,
which somehow defeats the purpose of pooling (but is fine in the
exceptional case).
The priority will be reset to C<0> after each run, all C<swap_sv> calls
will be undone, tracing will be disabled, the description will be reset
and the default output filehandle gets restored, so you can change all
these. Otherwise the coro will be re-used "as-is": most notably if you
change other per-coro global stuff such as C<$/> you I<must needs> revert
that change, which is most simply done by using local as in: C<< local $/
>>.
The idle pool size is limited to C<8> idle coros (this can be
adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle
coros as required.
If you are concerned about pooled coros 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 32kb
(adjustable via $Coro::POOL_RSS) it will also be destroyed.
=back
=head1 STATIC METHODS
Static methods are actually functions that implicitly operate on the
current coro.
=over 4
=item schedule
Calls the scheduler. The scheduler will find the next coro that is
to be run from the ready queue and switches to it. The next coro
to be run is simply the one with the highest priority that is longest
in its ready queue. If there is no coro ready, it will call the
C<$Coro::idle> hook.
Please note that the current coro will I<not> be put into the ready
queue, so calling this function usually means you will never be called
again unless something else (e.g. an event handler) calls C<< ->ready >>,
thus waking you up.
This makes C<schedule> I<the> generic method to use to block the current
coro and wait for events: first you remember the current coro in
a variable, then arrange for some callback of yours to call C<< ->ready
>> on that once some event happens, and last you call C<schedule> to put
yourself to sleep. Note that a lot of things can wake your coro up,
so you need to check whether the event indeed happened, e.g. by storing the
status in a variable.
See B<HOW TO WAIT FOR A CALLBACK>, below, for some ways to wait for callbacks.
=item cede
"Cede" to other coros. This function puts the current coro into
the ready queue and calls C<schedule>, which has the effect of giving
up the current "timeslice" to other coros of the same or higher
priority. Once your coro gets its turn again it will automatically be
resumed.
This function is often called C<yield> in other languages.
=item Coro::cede_notself
Works like cede, but is not exported by default and will cede to I<any>
coro, regardless of priority. This is useful sometimes to ensure
progress is made.
=item terminate [arg...]
Terminates the current coro with the given status values (see
L<cancel>). The values will not be copied, but referenced directly.
=item Coro::on_enter BLOCK, Coro::on_leave BLOCK
These function install enter and leave winders in the current scope. The
enter block will be executed when on_enter is called and whenever the
current coro is re-entered by the scheduler, while the leave block is
executed whenever the current coro is blocked by the scheduler, and
also when the containing scope is exited (by whatever means, be it exit,
die, last etc.).
I<Neither invoking the scheduler, nor exceptions, are allowed within those
BLOCKs>. That means: do not even think about calling C<die> without an
Since both BLOCKs are tied to the current scope, they will automatically
be removed when the current scope exits.
These functions implement the same concept as C<dynamic-wind> in scheme
does, and are useful when you want to localise some resource to a specific
coro.
They slow down thread switching considerably for coros that use them
(about 40% for a BLOCK with a single assignment, so thread switching is
still reasonably fast if the handlers are fast).
These functions are best understood by an example: The following function
will change the current timezone to "Antarctica/South_Pole", which
requires a call to C<tzset>, but by using C<on_enter> and C<on_leave>,
which remember/change the current timezone and restore the previous
value, respectively, the timezone is only changed for the coro that
installed those handlers.
use POSIX qw(tzset);
async {
$ENV{TZ} = $old_tz;
tzset; # restore old value
};
# at this place, the timezone is Antarctica/South_Pole,
# without disturbing the TZ of any other coro.
};
This can be used to localise about any resource (locale, uid, current
working directory etc.) to a block, despite the existence of other
coros.
Another interesting example implements time-sliced multitasking using
interval timers (this could obviously be optimised, but does the job):
# "timeslice" the given block
};
=item killall
Kills/terminates/cancels all coros except the currently running one.
Note that while this will try to free some of the main interpreter
resources if the calling coro isn't the main coro, but one
cannot free all of them, so if a coro that is not the main coro
calls this function, there will be some one-time resource leak.
=cut
sub killall {
=back
=head1 CORO OBJECT METHODS
These are the methods you can call on coro objects (or to create
them).
=over 4
=item new Coro \&sub [, @args...]
Create a new coro and return it. When the sub returns, the coro
automatically terminates as if C<terminate> with the returned values were
called. To make the coro run you must first put it into the ready
queue by calling the ready method.
See C<async> and C<Coro::State::new> for additional info about the
coro environment.
=cut
sub _coro_run {
terminate &{+shift};
}
=item $success = $coro->ready
Put the given coro into the end of its ready queue (there is one
queue for each priority) and return true. If the coro is already in
the ready queue, do nothing and return false.
This ensures that the scheduler will resume this coro automatically
once all the coro of higher priority and all coro of the same
priority that were put into the ready queue earlier have been resumed.
=item $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.
=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
against spurious wakeups, and the one in the Coro family certainly do
that.
=item $state->is_new
The name "zombie" stems from UNIX culture, where a process that has
exited and only stores and exit status and no other resources is called a
"zombie".
=item $is_ready = $coro->is_ready
Returns true iff the Coro object is in the ready queue. Unless the Coro
object gets destroyed, it will eventually be scheduled by the scheduler.
=item $is_running = $coro->is_running
Returns true iff the Coro object is currently running. Only one Coro object
can ever be in the running state (but it currently is possible to have
multiple running Coro::States).
=item $is_suspended = $coro->is_suspended
Returns true iff this Coro object has been suspended. Suspended Coros will
not ever be scheduled.
=item $coro->cancel ($arg...)
Terminate the given Coro thread and make it return the given arguments as
status (default: an empty list). Never returns if the Coro is the
current Coro.
This is a rather brutal way to free a coro, with some limitations - if
the thread is inside a C callback that doesn't expect to be canceled,
bad things can happen, or if the cancelled thread insists on running
complicated cleanup handlers that rely on its thread context, things will
not work.
The resources of the Coro are usually freed (or destructed) before this
call returns, but this can be delayed for an indefinite amount of time, as
in some cases the manager thread has to run first to actually destruct the
Coro object.
=item $coro->safe_cancel ($arg...)
Works mostly like C<< ->cancel >>, but is inherently "safer", and
consequently, can fail with an exception in cases the thread is not in a
cancellable state. Essentially, C<< ->safe_cancel >> is a C<< ->cancel >>
with extra checks before canceling.
This call returns true when it could cancel the thread, or croaks with an
error otherwise (i.e. it either returns true or doesn't return at all).
Why the weird interface? Well, there are two common models on how and
when to cancel things. In the first, you have the expectation that your
coro thread can be cancelled when you want to cancel it - if the thread
isn't cancellable, this would be a bug somewhere, so C<< ->safe_cancel >>
croaks to notify of the bug.
In the second model you sometimes want to ask nicely to cancel a thread,
but if it's not a good time, well, then don't cancel. This can be done
relatively easy like this:
if (! eval { $coro->safe_cancel }) {
warn "unable to cancel thread: $@";
}
However, what you never should do is first try to cancel "safely" and
if that fails, cancel the "hard" way with C<< ->cancel >>. That makes
no sense: either you rely on being able to execute cleanup code in your
thread context, or you don't. If you do, then C<< ->safe_cancel >> is the
only way, and if you don't, then C<< ->cancel >> is always faster and more
direct.
=item $coro->schedule_to
Puts the current coro to sleep (like C<Coro::schedule>), but instead
of continuing with the next coro from the ready queue, always switch to
the given coro object (regardless of priority etc.). The readyness
state of that coro isn't changed.
This is an advanced method for special cases - I'd love to hear about any
uses for this one.
=item $coro->cede_to
Like C<schedule_to>, but puts the current coro into the ready
queue. This has the effect of temporarily switching to the given
coro, and continuing some time later.
This is an advanced method for special cases - I'd love to hear about any
uses for this one.
=item $coro->throw ([$scalar])
If C<$throw> is specified and defined, it will be thrown as an exception
inside the coro at the next convenient point in time. Otherwise
clears the exception object.
Coro will check for the exception each time a schedule-like-function
returns, i.e. after each C<schedule>, C<cede>, C<< Coro::Semaphore->down
>>, C<< Coro::Handle->readable >> and so on. Most of those functions (all
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 either C<cancel> or C<safe_cancel
>to ask a coro 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 coro with a signal (in this case, a scalar).
=item $coro->join
Wait until the coro terminates and return any values given to the
C<terminate> or C<cancel> functions. C<join> can be called concurrently
from multiple threads, and all will be resumed and given the status
return once the C<$coro> terminates.
=item $coro->on_destroy (\&cb)
Registers a callback that is called when this coro thread gets destroyed,
that is, after it's resources have been freed but before it is joined. The
callback gets passed the terminate/cancel arguments, if any, and I<must
not> die, under any circumstances.
There can be any number of C<on_destroy> callbacks per coro, and there is
currently no way to remove a callback once added.
=item $oldprio = $coro->prio ($newprio)
Sets (or gets, if the argument is missing) the priority of the
coro thread. Higher priority coro get run before lower priority
coros. Priorities are small signed integers (currently -4 .. +3),
that you can refer to using PRIO_xxx constants (use the import tag :prio
to get then):
PRIO_MAX > PRIO_HIGH > PRIO_NORMAL > PRIO_LOW > PRIO_IDLE > PRIO_MIN
3 > 1 > 0 > -1 > -3 > -4
# set priority to HIGH
current->prio (PRIO_HIGH);
The idle coro thread ($Coro::idle) always has a lower priority than any
existing coro.
Changing the priority of the current coro will take effect immediately,
but changing the priority of a coro in the ready queue (but not running)
will only take effect after the next schedule (of that coro). This is a
bug that will be fixed in some future version.
=item $newprio = $coro->nice ($change)
Similar to C<prio>, but subtract the given value from the priority (i.e.
higher values mean lower priority, just as in UNIX's nice command).
=item $olddesc = $coro->desc ($newdesc)
Sets (or gets in case the argument is missing) the description for this
coro thread. This is just a free-form string you can associate with a
coro.
This method simply sets the C<< $coro->{desc} >> member to the given
string. You can modify this member directly if you wish, and in fact, this
is often preferred to indicate major processing states that can then be
seen for example in a L<Coro::Debug> session:
sub my_long_function {
=over 4
=item Coro::nready
Returns the number of coro that are currently in the ready state,
i.e. that can be switched to by calling C<schedule> directory or
indirectly. The value C<0> means that the only runnable coro is the
currently running one, so C<cede> would have no effect, and C<schedule>
would cause a deadlock unless there is an idle handler that wakes up some
coro.
=item my $guard = Coro::guard { ... }
This function still exists, but is deprecated. Please use the
C<Guard::guard> function instead.
This utility function takes a BLOCK or code reference and "unblocks" it,
returning a new coderef. Unblocking means that calling the new coderef
will return immediately without blocking, returning nothing, while the
original code ref will be called (with parameters) from within another
coro.
The reason this function exists is that many event libraries (such as
the venerable L<Event|Event> module) are not thread-safe (a weaker form
of reentrancy). This means you must not block within event callbacks,
otherwise you might suffer from crashes or worse. The only event library
Coro will try to catch you when you block in the event loop
("FATAL: $Coro::idle blocked itself"), but this is just best effort and
only works when you do not run your own event loop.
This function allows your callbacks to block by executing them in another
coro where it is safe to block. One example where blocking is handy
is when you use the L<Coro::AIO|Coro::AIO> functions to save results to
disk, for example.
In short: simply use C<unblock_sub { ... }> instead of C<sub { ... }> when
creating event callbacks that want to block.
If your handler does not plan to block (e.g. simply sends a message to
another coro, or puts some other coro into the ready queue), there is
no reason to use C<unblock_sub>.
Note that you also need to use C<unblock_sub> for any other callbacks that
are indirectly executed by any C-based event loop. For example, when you
use a module that uses L<AnyEvent> (and you use L<Coro::AnyEvent>) and it
=cut
our @unblock_queue;
# we create a special coro because we want to cede,
# 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 = new Coro sub {
while () {
while (my $cb = pop @unblock_queue) {
&async_pool (@$cb);
# for short-lived callbacks, this reduces pressure on the coro pool
# as the chance is very high that the async_poll coro will be back
# in the idle state when cede returns
cede;
}
schedule; # sleep well
}
=item $cb = rouse_cb
Create and return a "rouse callback". That's a code reference that,
when called, will remember a copy of its arguments and notify the owner
coro of the callback.
See the next function.
=item @args = rouse_wait [$cb]
Wait for the specified rouse callback (or the last one that was created in
this coro).
As soon as the callback is invoked (or when the callback was invoked
before C<rouse_wait>), it will return the arguments originally passed to
the rouse callback. In scalar context, that means you get the I<last>
argument, just as if C<rouse_wait> had a C<return ($a1, $a2, $a3...)>
1;
=head1 HOW TO WAIT FOR A CALLBACK
It is very common for a coro to wait for some callback to be
called. This occurs naturally when you use coro in an otherwise
event-based program, or when you use event-based libraries.
These typically register a callback for some event, and call that callback
when the event occurred. In a coro, however, you typically want to
just wait for the event, simplyifying things.
For example C<< AnyEvent->child >> registers a callback to be called when
a specific child has exited:
my $child_watcher = AnyEvent->child (pid => $pid, cb => sub { ... });
But from within a coro, you often just want to write this:
my $status = wait_for_child $pid;
Coro offers two functions specifically designed to make this easy,
C<rouse_cb> and C<rouse_wait>.
The first function, C<rouse_cb>, generates and returns a callback that,
when invoked, will save its arguments and notify the coro that
created the callback.
The second function, C<rouse_wait>, waits for the callback to be called
(by calling C<schedule> to go to sleep) and returns the arguments
originally passed to the callback.
you can roll your own, using C<schedule> and C<ready>:
sub wait_for_child($) {
my ($pid) = @_;
# store the current coro in $current,
# and provide result variables for the closure passed to ->child
my $current = $Coro::current;
my ($done, $rstatus);
# pass a closure to ->child
=item fork with pthread backend
When Coro is compiled using the pthread backend (which isn't recommended
but required on many BSDs as their libcs are completely broken), then
coro will not survive a fork. There is no known workaround except to
fix your libc and use a saner backend.
=item perl process emulation ("threads")
This module is not perl-pseudo-thread-safe. You should only ever use this
performance, even when not used.
Attempts to use threads created in another emulated process will crash
("cleanly", with a null pointer exception).
=item coro switching is not signal safe
You must not switch to another coro from within a signal handler (only
relevant with %SIG - most event libraries provide safe signals), I<unless>
you are sure you are not interrupting a Coro function.
That means you I<MUST NOT> call any function that might "block" the
current coro - C<cede>, C<schedule> C<< Coro::Semaphore->down >> or
anything that calls those. Everything else, including calling C<ready>,
works.
=back
Corona
view release on metacpan or search on metacpan
lib/Corona.pm view on Meta::CPAN
Corona - Coro based PSGI web server
=head1 SYNOPSIS
corona --listen :9090 app.psgi
=head1 DESCRIPTION
Corona is a Coro based Plack web server. It uses L<Net::Server::Coro>
under the hood, which means we have coroutines (threads) for each
socket, active connections and a main loop.
Because it's Coro based your web application can actually block with
I/O wait as long as it yields when being blocked, to the other
coroutine either explicitly with C<cede> or automatically (via Coro::*
magic).
# your web application
use Coro::LWP;
my $content = LWP::Simple::get($url); # this yields to other threads when IO blocks
Coteng
view release on metacpan or search on metacpan
cpanfile.snapshot view on Meta::CPAN
DBD::Gofer::Policy::Base 0.010088
DBD::Gofer::Policy::classic 0.010088
DBD::Gofer::Policy::pedantic 0.010088
DBD::Gofer::Policy::rush 0.010088
DBD::Gofer::Transport::Base 0.014121
DBD::Gofer::Transport::corostream undef
DBD::Gofer::Transport::null 0.010088
DBD::Gofer::Transport::pipeone 0.010088
DBD::Gofer::Transport::stream 0.014599
DBD::Gofer::db 0.015327
DBD::Gofer::dr 0.015327
Crypt-Bear
view release on metacpan or search on metacpan
src/ssl/ssl_engine.c view on Meta::CPAN
/*
* IMPLEMENTATION NOTES
* ====================
*
* The handshake processor is written in T0 and runs as a coroutine.
* It receives the contents of all records except application data, and
* is responsible for producing the contents of all records except
* application data.
*
* A state flag is maintained, which specifies whether application data
src/ssl/ssl_engine.c view on Meta::CPAN
* application, and incoming application data records trigger an error.
*
*
* Records of type handshake, alert or change-cipher-spec are handled
* by the handshake processor. The handshake processor is written in T0
* and runs as a coroutine; it gets invoked whenever one of the following
* situations is reached:
*
* -- An incoming record has type handshake, alert or change-cipher-spec,
* and yields data that can be read (zero-length records are thus
* ignored).
Crypt-Diceware-Wordlist-NL
view release on metacpan or search on metacpan
lib/Crypt/Diceware/Wordlist/NL.pm view on Meta::CPAN
15663 cool
15664 cordon
15665 corgi
15666 corner
16111 cornet
16112 corona
16113 corps
16114 corpus
16115 corso
16116 cortex
16121 corvee
Crypt-Diceware
view release on metacpan or search on metacpan
lib/Crypt/Diceware/Wordlist/Common.pm view on Meta::CPAN
contessa contest continual contort contrail contrary contrite contrive
control contumacy contuse contusion convene converge convert convex
convivial convolute convolve convoy convulse cookbook cooked cookie cookout
cool cooled cooperate coos coped copies copious copiously copout copped
copper coquette cordon cork corkscrew corm corn cornered cornice cornmeal
corollary coronet corporal corporate corporeal corps corpse corpulent
corpuscle correctly correlate corrode corroded corrosion corrosive
corrupted corset corseted cortical cosmetic cosmetics cosmic cosmogony
cosmology cosmonaut cosmos countess couplers courage course courser
courtesy cousin covenant cover covered covering covert covey cowardly cower
cowled coxswain coy cozying crabs crack cracked cracker crackers crackpot
lib/Crypt/Diceware/Wordlist/Common.pm view on Meta::CPAN
daunting dauntless daylight daypack daytime daywear dazed dazedly dazzle
dazzled dba deadened deadlock deafening deal dearest dearth debase
debatable debated debonair debrief debut decadence decagon decagram
decaliter decalogue decameter decamp decapod decayed deceit deceitful
deceive decency decent deception deceptive decide decides deciding
deciduous decimal decimate decipher decisive decker decks decorate decorous
decoy decoys decrease decreed decrepit decrying dedicate deduce deduces
deed deep deepen deepens deer deface defalcate defame defamed defanged
default defaults defective defendant defensive defer deference defiant
deficient defiled definite deflate deflates deflect deforest deform
deformed deformity defraud defray deft degrade degraded degrading dehydrate
Crypt-HSXKPasswd
view release on metacpan or search on metacpan
lib/Crypt/HSXKPasswd/Dictionary/ES.pm view on Meta::CPAN
'cornucopia',
'cornuda',
'cornudas',
'cornudo',
'cornudos',
'coro',
'corolaria',
'corolarias',
'corolario',
'corolarios',
'corona',
'coronaciones',
'coronación',
'coronado',
'coronamento',
'coronar',
'coronas',
'coronel',
'coroneles',
'coronilla',
'coronillas',
'coros',
'corpiño',
'corpiños',
'corporación',
'corporal',
'corporales',
lib/Crypt/HSXKPasswd/Dictionary/ES.pm view on Meta::CPAN
'decorasteis',
'decore',
'decoremos',
'decoren',
'decores',
'decoro',
'decoros',
'decorosa',
'decorosas',
'decoroso',
'decorosos',
'decorábamos',
'decoráis',
'decorándola',
'decorándolas',
'decorándolo',
lib/Crypt/HSXKPasswd/Dictionary/ES.pm view on Meta::CPAN
'indecisa',
'indecisas',
'indeciso',
'indecisos',
'indeclinable',
'indecorosa',
'indecorosas',
'indecoroso',
'indecorosos',
'indefectible',
'indefendible',
'indefensa',
'indefensas',
'indefensión',
lib/Crypt/HSXKPasswd/Dictionary/ES.pm view on Meta::CPAN
'licorera',
'licoreras',
'licores',
'licorista',
'licoristas',
'licorosa',
'licorosas',
'licoroso',
'licorosos',
'licuable',
'licuables',
'licuación',
'licuada',
'licuadas',
lib/Crypt/HSXKPasswd/Dictionary/ES.pm view on Meta::CPAN
'renca',
'rencas',
'renco',
'rencor',
'rencores',
'rencorosa',
'rencorosas',
'rencoroso',
'rencorosos',
'rencos',
'rendiciones',
'rendición',
'rendid',
'rendida',
Crypt-NSS-X509
view release on metacpan or search on metacpan
certs/root.ca view on Meta::CPAN
fY+BUZo7jYn0TZNmezwD7dOaHZrzZVD1oNB1ny+v8OqCQ5j4aZyJecRDjkZy42Q2Eq/3JR44iZB3
fsNrarnDy0RLrHiQi+fHLB5LEUTINFInzQpdn4XBidUaePKVEFMy3YCEZnXZtWgo+2EuvoSoOMCZ
EoalHmdkrQYuL6lwhceWD3yJZfWOQ1QOq92lgDmUYMA0yZZwLKMS9R9Ie70cfmu3nZD0Ijuu+Pwq
yvqCUqDvr0tVk+vBtfAii6w0TiYiBKGHLHVKt+V9E9e4DGTANtLJL4YSjCMJwRuCO3NJo2pXh5Tl
1njFmUNj403gdy3hZZlyaQQaRwnmDwFWJPsfvw55qVguucQJAX6Vum0ABj6y6koQOdjQK/W/7HW/
lwLFCRsI3FU34oH7N4RDYiDK51ZLZer+bMEkkyShNOsF/5oirpt9P/FlUQqmMGqz9IgcgA38coro
g14=
-----END CERTIFICATE-----
Taiwan GRCA
===========
Crypt-XkcdPassword
view release on metacpan or search on metacpan
lib/Crypt/XkcdPassword/Words/EN.pm view on Meta::CPAN
edgy
donkey
diseases
didn
curtis
coroner
confessing
cologne
cedar
ca
bruise
CtrlO-Crypt-XkcdPassword
view release on metacpan or search on metacpan
lib/CtrlO/Crypt/XkcdPassword/Wordlist/eff_large.pm view on Meta::CPAN
cornflake
cornhusk
cornmeal
cornstalk
corny
coronary
coroner
corporal
corporate
corral
correct
corridor
DBD-SQLcipher
view release on metacpan or search on metacpan
#define SQLITE_FactorOutConst 0x0008 /* Constant factoring */
/* not used 0x0010 // Was: SQLITE_IdxRealAsInt */
#define SQLITE_DistinctOpt 0x0020 /* DISTINCT using indexes */
#define SQLITE_CoverIdxScan 0x0040 /* Covering index scans */
#define SQLITE_OrderByIdxJoin 0x0080 /* ORDER BY of joins via index */
#define SQLITE_SubqCoroutine 0x0100 /* Evaluate subqueries as coroutines */
#define SQLITE_Transitive 0x0200 /* Transitive constraints */
#define SQLITE_OmitNoopJoin 0x0400 /* Omit unused tables in joins */
#define SQLITE_Stat34 0x0800 /* Use STAT3 or STAT4 data */
#define SQLITE_AllOpts 0xffff /* All optimizations */
break;
}
/* Opcode: InitCoroutine P1 P2 P3 * *
**
** Set up register P1 so that it will Yield to the coroutine
** located at address P3.
**
** If P2!=0 then the coroutine implementation immediately follows
** this opcode. So jump over the coroutine implementation to
** address P2.
**
** See also: EndCoroutine
*/
case OP_InitCoroutine: { /* jump */
}
/* Opcode: Yield P1 P2 * * *
**
** Swap the program counter with the value in register P1. This
** has the effect of yielding to a coroutine.
**
** If the coroutine that is launched by this instruction ends with
** Yield or Return then continue to the next instruction. But if
** the coroutine launched by this instruction ends with
** EndCoroutine, then jump to P2 rather than continuing with the
** next instruction.
**
** See also: InitCoroutine
*/
** loop over the rows in the SELECT
** load values into registers R..R+n
** yield X
** end loop
** cleanup after the SELECT
** end-coroutine X
** B: open write cursor to <table> and its indices
** C: yield X, at EOF goto D
** insert the select result into <table> from R..R+n
** goto C
** D: cleanup
if( pTrigger || readsTable(pParse, iDb, pTab) ){
useTempTable = 1;
}
if( useTempTable ){
/* Invoke the coroutine to extract information from the SELECT
** and add it to a transient table srcTab. The code generated
** here is from the 4th template:
**
** B: open temp table
** L: yield X, goto M at EOF
return rc;
}
#endif /* SQLITE_OMIT_COMPOUND_SELECT */
/*
** Code an output subroutine for a coroutine implementation of a
** SELECT statment.
**
** The data to be output is contained in pIn->iSdst. There are
** pIn->nSdst columns to be output. pDest is where the output should
** be sent.
** <selectA> <operator> <selectB> ORDER BY <orderbylist>
**
** <operator> is one of UNION ALL, UNION, EXCEPT, or INTERSECT. The idea
** is to code both <selectA> and <selectB> with the ORDER BY clause as
** co-routines. Then run the co-routines in parallel and merge the results
** into the output. In addition to the two coroutines (called selectA and
** selectB) there are 7 subroutines:
**
** outA: Move the output of the selectA coroutine into the output
** of the compound query.
**
** outB: Move the output of the selectB coroutine into the output
** of the compound query. (Only generated for UNION and
** UNION ALL. EXCEPT and INSERTSECT never output a row that
** appears only in B.)
**
** AltB: Called when there is data from both coroutines and A<B.
**
** AeqB: Called when there is data from both coroutines and A==B.
**
** AgtB: Called when there is data from both coroutines and A>B.
**
** EofA: Called when data is exhausted from selectA.
**
** EofB: Called when data is exhausted from selectB.
**
** Duplicate removal in the UNION, EXCEPT, and INTERSECT cases is handled
** within the output subroutine. The regPrev register set holds the previously
** output value. A comparison is made against this value and the output
** is skipped if the next results would be the same as the previous.
**
** The implementation plan is to implement the two coroutines and seven
** subroutines first, then put the control logic at the bottom. Like this:
**
** goto Init
** coA: coroutine for left query (A)
** coB: coroutine for right query (B)
** outA: output one row of A
** outB: output one row of B (UNION and UNION ALL only)
** EofA: ...
** EofB: ...
** AltB: ...
** AeqB: ...
** AgtB: ...
** Init: initialize coroutine registers
** yield coA
** if eof(A) goto EofA
** yield coB
** if eof(B) goto EofB
** Cmpr: Compare A, B
SelectDest *pDest /* What to do with query results */
){
int i, j; /* Loop counters */
Select *pPrior; /* Another SELECT immediately to our left */
Vdbe *v; /* Generate code to this VDBE */
SelectDest destA; /* Destination for coroutine A */
SelectDest destB; /* Destination for coroutine B */
int regAddrA; /* Address register for select-A coroutine */
int regAddrB; /* Address register for select-B coroutine */
int addrSelectA; /* Address of the select-A coroutine */
int addrSelectB; /* Address of the select-B coroutine */
int regOutA; /* Address register for the output-A subroutine */
int regOutB; /* Address register for the output-B subroutine */
int addrOutA; /* Address of the output-A subroutine */
int addrOutB = 0; /* Address of the output-B subroutine */
int addrEofA; /* Address of the select-A-exhausted subroutine */
regOutA = ++pParse->nMem;
regOutB = ++pParse->nMem;
sqlite3SelectDestInit(&destA, SRT_Coroutine, regAddrA);
sqlite3SelectDestInit(&destB, SRT_Coroutine, regAddrB);
/* Generate a coroutine to evaluate the SELECT statement to the
** left of the compound operator - the "A" select.
*/
addrSelectA = sqlite3VdbeCurrentAddr(v) + 1;
j1 = sqlite3VdbeAddOp3(v, OP_InitCoroutine, regAddrA, 0, addrSelectA);
VdbeComment((v, "left SELECT"));
explainSetInteger(iSub1, pParse->iNextSelectId);
sqlite3Select(pParse, pPrior, &destA);
sqlite3VdbeAddOp1(v, OP_EndCoroutine, regAddrA);
sqlite3VdbeJumpHere(v, j1);
/* Generate a coroutine to evaluate the SELECT statement on
** the right - the "B" select
*/
addrSelectB = sqlite3VdbeCurrentAddr(v) + 1;
j1 = sqlite3VdbeAddOp3(v, OP_InitCoroutine, regAddrB, 0, addrSelectB);
VdbeComment((v, "right SELECT"));
DBD-SQLeet
view release on metacpan or search on metacpan
break;
}
/* Opcode: InitCoroutine P1 P2 P3 * *
**
** Set up register P1 so that it will Yield to the coroutine
** located at address P3.
**
** If P2!=0 then the coroutine implementation immediately follows
** this opcode. So jump over the coroutine implementation to
** address P2.
**
** See also: EndCoroutine
*/
case OP_InitCoroutine: { /* jump */
}
/* Opcode: Yield P1 P2 * * *
**
** Swap the program counter with the value in register P1. This
** has the effect of yielding to a coroutine.
**
** If the coroutine that is launched by this instruction ends with
** Yield or Return then continue to the next instruction. But if
** the coroutine launched by this instruction ends with
** EndCoroutine, then jump to P2 rather than continuing with the
** next instruction.
**
** See also: InitCoroutine
*/
** loop over the rows in the SELECT
** load values into registers R..R+n
** yield X
** end loop
** cleanup after the SELECT
** end-coroutine X
** B: open write cursor to <table> and its indices
** C: yield X, at EOF goto D
** insert the select result into <table> from R..R+n
** goto C
** D: cleanup
if( pTrigger || readsTable(pParse, iDb, pTab) ){
useTempTable = 1;
}
if( useTempTable ){
/* Invoke the coroutine to extract information from the SELECT
** and add it to a transient table srcTab. The code generated
** here is from the 4th template:
**
** B: open temp table
** L: yield X, goto M at EOF
" do not have the same number of result columns", selectOpName(p->op));
}
}
/*
** Code an output subroutine for a coroutine implementation of a
** SELECT statment.
**
** The data to be output is contained in pIn->iSdst. There are
** pIn->nSdst columns to be output. pDest is where the output should
** be sent.
** <selectA> <operator> <selectB> ORDER BY <orderbylist>
**
** <operator> is one of UNION ALL, UNION, EXCEPT, or INTERSECT. The idea
** is to code both <selectA> and <selectB> with the ORDER BY clause as
** co-routines. Then run the co-routines in parallel and merge the results
** into the output. In addition to the two coroutines (called selectA and
** selectB) there are 7 subroutines:
**
** outA: Move the output of the selectA coroutine into the output
** of the compound query.
**
** outB: Move the output of the selectB coroutine into the output
** of the compound query. (Only generated for UNION and
** UNION ALL. EXCEPT and INSERTSECT never output a row that
** appears only in B.)
**
** AltB: Called when there is data from both coroutines and A<B.
**
** AeqB: Called when there is data from both coroutines and A==B.
**
** AgtB: Called when there is data from both coroutines and A>B.
**
** EofA: Called when data is exhausted from selectA.
**
** EofB: Called when data is exhausted from selectB.
**
** Duplicate removal in the UNION, EXCEPT, and INTERSECT cases is handled
** within the output subroutine. The regPrev register set holds the previously
** output value. A comparison is made against this value and the output
** is skipped if the next results would be the same as the previous.
**
** The implementation plan is to implement the two coroutines and seven
** subroutines first, then put the control logic at the bottom. Like this:
**
** goto Init
** coA: coroutine for left query (A)
** coB: coroutine for right query (B)
** outA: output one row of A
** outB: output one row of B (UNION and UNION ALL only)
** EofA: ...
** EofB: ...
** AltB: ...
** AeqB: ...
** AgtB: ...
** Init: initialize coroutine registers
** yield coA
** if eof(A) goto EofA
** yield coB
** if eof(B) goto EofB
** Cmpr: Compare A, B
SelectDest *pDest /* What to do with query results */
){
int i, j; /* Loop counters */
Select *pPrior; /* Another SELECT immediately to our left */
Vdbe *v; /* Generate code to this VDBE */
SelectDest destA; /* Destination for coroutine A */
SelectDest destB; /* Destination for coroutine B */
int regAddrA; /* Address register for select-A coroutine */
int regAddrB; /* Address register for select-B coroutine */
int addrSelectA; /* Address of the select-A coroutine */
int addrSelectB; /* Address of the select-B coroutine */
int regOutA; /* Address register for the output-A subroutine */
int regOutB; /* Address register for the output-B subroutine */
int addrOutA; /* Address of the output-A subroutine */
int addrOutB = 0; /* Address of the output-B subroutine */
int addrEofA; /* Address of the select-A-exhausted subroutine */
sqlite3SelectDestInit(&destA, SRT_Coroutine, regAddrA);
sqlite3SelectDestInit(&destB, SRT_Coroutine, regAddrB);
ExplainQueryPlan((pParse, 1, "MERGE (%s)", selectOpName(p->op)));
/* Generate a coroutine to evaluate the SELECT statement to the
** left of the compound operator - the "A" select.
*/
addrSelectA = sqlite3VdbeCurrentAddr(v) + 1;
addr1 = sqlite3VdbeAddOp3(v, OP_InitCoroutine, regAddrA, 0, addrSelectA);
VdbeComment((v, "left SELECT"));
ExplainQueryPlan((pParse, 1, "LEFT"));
sqlite3Select(pParse, pPrior, &destA);
sqlite3VdbeEndCoroutine(v, regAddrA);
sqlite3VdbeJumpHere(v, addr1);
/* Generate a coroutine to evaluate the SELECT statement on
** the right - the "B" select
*/
addrSelectB = sqlite3VdbeCurrentAddr(v) + 1;
addr1 = sqlite3VdbeAddOp3(v, OP_InitCoroutine, regAddrB, 0, addrSelectB);
VdbeComment((v, "right SELECT"));
( run in 0.527 second using v1.01-cache-2.11-cpan-87723dcf8b7 )