Result:
found 484 distributions and 1145 files matching your query !
( run in 0.919 )
Catmandu-MediaWiki
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
Catmandu-SRU
view release on metacpan or search on metacpan
t/files/marcxml_ns_prefix.xml view on Meta::CPAN
<mytestprefix:subfield code="d">1758-1832</mytestprefix:subfield>
<mytestprefix:subfield code="0">98629</mytestprefix:subfield>
</mytestprefix:datafield>
<mytestprefix:datafield tag="240" ind1="1" ind2="0">
<mytestprefix:subfield code="a">Was verklärt im Sturmes Drang</mytestprefix:subfield>
<mytestprefix:subfield code="m">coro</mytestprefix:subfield>
<mytestprefix:subfield code="r">c</mytestprefix:subfield>
<mytestprefix:subfield code="0">3917677</mytestprefix:subfield>
</mytestprefix:datafield>
<mytestprefix:datafield tag="245" ind1="1" ind2="0">
<mytestprefix:subfield code="a">[without title]</mytestprefix:subfield>
t/files/marcxml_ns_prefix.xml view on Meta::CPAN
<mytestprefix:subfield code="d">1758-1832</mytestprefix:subfield>
<mytestprefix:subfield code="0">98629</mytestprefix:subfield>
</mytestprefix:datafield>
<mytestprefix:datafield tag="240" ind1="1" ind2="0">
<mytestprefix:subfield code="a">Patriotisches Rheinweinlied der Elfer</mytestprefix:subfield>
<mytestprefix:subfield code="m">coro maschile</mytestprefix:subfield>
<mytestprefix:subfield code="r">C</mytestprefix:subfield>
<mytestprefix:subfield code="0">3917679</mytestprefix:subfield>
</mytestprefix:datafield>
<mytestprefix:datafield tag="245" ind1="1" ind2="0">
<mytestprefix:subfield code="a">[caption title, p. 6:] [with pencil: "No 10."] Rheinweinlied</mytestprefix:subfield>
t/files/marcxml_ns_prefix.xml view on Meta::CPAN
<mytestprefix:subfield code="d">1758-1832</mytestprefix:subfield>
<mytestprefix:subfield code="0">98629</mytestprefix:subfield>
</mytestprefix:datafield>
<mytestprefix:datafield tag="240" ind1="1" ind2="0">
<mytestprefix:subfield code="a">Lauriger Horatius</mytestprefix:subfield>
<mytestprefix:subfield code="m">V(3), coro maschile</mytestprefix:subfield>
<mytestprefix:subfield code="r">D</mytestprefix:subfield>
<mytestprefix:subfield code="0">3917684</mytestprefix:subfield>
</mytestprefix:datafield>
<mytestprefix:datafield tag="245" ind1="1" ind2="0">
<mytestprefix:subfield code="a">[caption title, p. 2:] 15 febr 14.</mytestprefix:subfield>
Cinnamon
view release on metacpan or search on metacpan
lib/Cinnamon/Runner.pm view on Meta::CPAN
my $task_name = $task->name;
my $concurrency_setting = CTX->get_param('concurrency') || {};
my $concurrency = $concurrency_setting->{$task_name} || scalar @$hosts;
while (my @target_hosts = splice @$hosts, 0, $concurrency) {
my @coros;
for my $host (@target_hosts) {
my $coro = async {
my $result = $class->execute($host, $task);
$all_results->{$host} = $result;
};
push @coros, $coro;
}
$_->join for @coros;
}
return $all_results;
}
ClarID-Tools
view release on metacpan or search on metacpan
share/icd10.json view on Meta::CPAN
"B9710": "Unspecified enterovirus as the cause of diseases classified elsewhere",
"B9711": "Coxsackievirus as the cause of diseases classified elsewhere",
"B9712": "Echovirus as the cause of diseases classified elsewhere",
"B9719": "Other enterovirus as the cause of diseases classified elsewhere",
"B972": "Coronavirus as the cause of diseases classified elsewhere",
"B9721": "SARS-associated coronavirus as the cause of diseases classified elsewhere",
"B9729": "Other coronavirus as the cause of diseases classified elsewhere",
"B973": "Retrovirus as the cause of diseases classified elsewhere",
"B9730": "Unspecified retrovirus as the cause of diseases classified elsewhere",
"B9731": "Lentivirus as the cause of diseases classified elsewhere",
"B9732": "Oncovirus as the cause of diseases classified elsewhere",
"B9733": "Human T-cell lymphotrophic virus, type I [HTLV-I] as the cause of diseases classified elsewhere",
share/icd10.json view on Meta::CPAN
"I20": "Angina pectoris",
"I200": "Unstable angina",
"I201": "Angina pectoris with documented spasm",
"I202": "Refractory angina pectoris",
"I208": "Other forms of angina pectoris",
"I2081": "Angina pectoris with coronary microvascular dysfunction",
"I2089": "Other forms of angina pectoris",
"I209": "Angina pectoris, unspecified",
"I21": "Acute myocardial infarction",
"I210": "ST elevation (STEMI) myocardial infarction of anterior wall",
"I2101": "ST elevation (STEMI) myocardial infarction involving left main coronary artery",
"I2102": "ST elevation (STEMI) myocardial infarction involving left anterior descending coronary artery",
"I2109": "ST elevation (STEMI) myocardial infarction involving other coronary artery of anterior wall",
"I211": "ST elevation (STEMI) myocardial infarction of inferior wall",
"I2111": "ST elevation (STEMI) myocardial infarction involving right coronary artery",
"I2119": "ST elevation (STEMI) myocardial infarction involving other coronary artery of inferior wall",
"I212": "ST elevation (STEMI) myocardial infarction of other sites",
"I2121": "ST elevation (STEMI) myocardial infarction involving left circumflex coronary artery",
"I2129": "ST elevation (STEMI) myocardial infarction involving other sites",
"I213": "ST elevation (STEMI) myocardial infarction of unspecified site",
"I214": "Non-ST elevation (NSTEMI) myocardial infarction",
"I219": "Acute myocardial infarction, unspecified",
"I21A": "Other type of myocardial infarction",
"I21A1": "Myocardial infarction type 2",
"I21A9": "Other myocardial infarction type",
"I21B": "Myocardial infarction with coronary microvascular dysfunction",
"I22": "Subsequent ST elevation (STEMI) and non-ST elevation (NSTEMI) myocardial infarction",
"I220": "Subsequent ST elevation (STEMI) myocardial infarction of anterior wall",
"I221": "Subsequent ST elevation (STEMI) myocardial infarction of inferior wall",
"I222": "Subsequent non-ST elevation (NSTEMI) myocardial infarction",
"I228": "Subsequent ST elevation (STEMI) myocardial infarction of other sites",
share/icd10.json view on Meta::CPAN
"I235": "Rupture of papillary muscle as current complication following acute myocardial infarction",
"I236": "Thrombosis of atrium, auricular appendage, and ventricle as current complications following acute myocardial infarction",
"I237": "Postinfarction angina",
"I238": "Other current complications following acute myocardial infarction",
"I24": "Other acute ischemic heart diseases",
"I240": "Acute coronary thrombosis not resulting in myocardial infarction",
"I241": "Dressler's syndrome",
"I248": "Other forms of acute ischemic heart disease",
"I2481": "Acute coronary microvascular dysfunction",
"I2489": "Other forms of acute ischemic heart disease",
"I249": "Acute ischemic heart disease, unspecified",
"I25": "Chronic ischemic heart disease",
"I251": "Atherosclerotic heart disease of native coronary artery",
"I2510": "Atherosclerotic heart disease of native coronary artery without angina pectoris",
"I2511": "Atherosclerotic heart disease of native coronary artery with angina pectoris",
"I25110": "Atherosclerotic heart disease of native coronary artery with unstable angina pectoris",
"I25111": "Atherosclerotic heart disease of native coronary artery with angina pectoris with documented spasm",
"I25112": "Atherosclerotic heart disease of native coronary artery with refractory angina pectoris",
"I25118": "Atherosclerotic heart disease of native coronary artery with other forms of angina pectoris",
"I25119": "Atherosclerotic heart disease of native coronary artery with unspecified angina pectoris",
"I252": "Old myocardial infarction",
"I253": "Aneurysm of heart",
"I254": "Coronary artery aneurysm and dissection",
"I2541": "Coronary artery aneurysm",
"I2542": "Coronary artery dissection",
"I255": "Ischemic cardiomyopathy",
"I256": "Silent myocardial ischemia",
"I257": "Atherosclerosis of coronary artery bypass graft(s) and coronary artery of transplanted heart with angina pectoris",
"I2570": "Atherosclerosis of coronary artery bypass graft(s), unspecified, with angina pectoris",
"I25700": "Atherosclerosis of coronary artery bypass graft(s), unspecified, with unstable angina pectoris",
"I25701": "Atherosclerosis of coronary artery bypass graft(s), unspecified, with angina pectoris with documented spasm",
"I25702": "Atherosclerosis of coronary artery bypass graft(s), unspecified, with refractory angina pectoris",
"I25708": "Atherosclerosis of coronary artery bypass graft(s), unspecified, with other forms of angina pectoris",
"I25709": "Atherosclerosis of coronary artery bypass graft(s), unspecified, with unspecified angina pectoris",
"I2571": "Atherosclerosis of autologous vein coronary artery bypass graft(s) with angina pectoris",
"I25710": "Atherosclerosis of autologous vein coronary artery bypass graft(s) with unstable angina pectoris",
"I25711": "Atherosclerosis of autologous vein coronary artery bypass graft(s) with angina pectoris with documented spasm",
"I25712": "Atherosclerosis of autologous vein coronary artery bypass graft(s) with refractory angina pectoris",
"I25718": "Atherosclerosis of autologous vein coronary artery bypass graft(s) with other forms of angina pectoris",
"I25719": "Atherosclerosis of autologous vein coronary artery bypass graft(s) with unspecified angina pectoris",
"I2572": "Atherosclerosis of autologous artery coronary artery bypass graft(s) with angina pectoris",
"I25720": "Atherosclerosis of autologous artery coronary artery bypass graft(s) with unstable angina pectoris",
"I25721": "Atherosclerosis of autologous artery coronary artery bypass graft(s) with angina pectoris with documented spasm",
"I25722": "Atherosclerosis of autologous artery coronary artery bypass graft(s) with refractory angina pectoris",
"I25728": "Atherosclerosis of autologous artery coronary artery bypass graft(s) with other forms of angina pectoris",
"I25729": "Atherosclerosis of autologous artery coronary artery bypass graft(s) with unspecified angina pectoris",
"I2573": "Atherosclerosis of nonautologous biological coronary artery bypass graft(s) with angina pectoris",
"I25730": "Atherosclerosis of nonautologous biological coronary artery bypass graft(s) with unstable angina pectoris",
"I25731": "Atherosclerosis of nonautologous biological coronary artery bypass graft(s) with angina pectoris with documented spasm",
"I25732": "Atherosclerosis of nonautologous biological coronary artery bypass graft(s) with refractory angina pectoris",
"I25738": "Atherosclerosis of nonautologous biological coronary artery bypass graft(s) with other forms of angina pectoris",
"I25739": "Atherosclerosis of nonautologous biological coronary artery bypass graft(s) with unspecified angina pectoris",
"I2575": "Atherosclerosis of native coronary artery of transplanted heart with angina pectoris",
"I25750": "Atherosclerosis of native coronary artery of transplanted heart with unstable angina",
"I25751": "Atherosclerosis of native coronary artery of transplanted heart with angina pectoris with documented spasm",
"I25752": "Atherosclerosis of native coronary artery of transplanted heart with refractory angina pectoris",
"I25758": "Atherosclerosis of native coronary artery of transplanted heart with other forms of angina pectoris",
"I25759": "Atherosclerosis of native coronary artery of transplanted heart with unspecified angina pectoris",
"I2576": "Atherosclerosis of bypass graft of coronary artery of transplanted heart with angina pectoris",
"I25760": "Atherosclerosis of bypass graft of coronary artery of transplanted heart with unstable angina",
"I25761": "Atherosclerosis of bypass graft of coronary artery of transplanted heart with angina pectoris with documented spasm",
"I25762": "Atherosclerosis of bypass graft of coronary artery of transplanted heart with refractory angina pectoris",
"I25768": "Atherosclerosis of bypass graft of coronary artery of transplanted heart with other forms of angina pectoris",
"I25769": "Atherosclerosis of bypass graft of coronary artery of transplanted heart with unspecified angina pectoris",
"I2579": "Atherosclerosis of other coronary artery bypass graft(s) with angina pectoris",
"I25790": "Atherosclerosis of other coronary artery bypass graft(s) with unstable angina pectoris",
"I25791": "Atherosclerosis of other coronary artery bypass graft(s) with angina pectoris with documented spasm",
"I25792": "Atherosclerosis of other coronary artery bypass graft(s) with refractory angina pectoris",
"I25798": "Atherosclerosis of other coronary artery bypass graft(s) with other forms of angina pectoris",
"I25799": "Atherosclerosis of other coronary artery bypass graft(s) with unspecified angina pectoris",
"I258": "Other forms of chronic ischemic heart disease",
"I2581": "Atherosclerosis of other coronary vessels without angina pectoris",
"I25810": "Atherosclerosis of coronary artery bypass graft(s) without angina pectoris",
"I25811": "Atherosclerosis of native coronary artery of transplanted heart without angina pectoris",
"I25812": "Atherosclerosis of bypass graft of coronary artery of transplanted heart without angina pectoris",
"I2582": "Chronic total occlusion of coronary artery",
"I2583": "Coronary atherosclerosis due to lipid rich plaque",
"I2584": "Coronary atherosclerosis due to calcified coronary lesion",
"I2585": "Chronic coronary microvascular dysfunction",
"I2589": "Other forms of chronic ischemic heart disease",
"I259": "Chronic ischemic heart disease, unspecified",
"I26": "Pulmonary embolism",
"I260": "Pulmonary embolism with acute cor pulmonale",
"I2601": "Septic pulmonary embolism with acute cor pulmonale",
share/icd10.json view on Meta::CPAN
"J120": "Adenoviral pneumonia",
"J121": "Respiratory syncytial virus pneumonia",
"J122": "Parainfluenza virus pneumonia",
"J123": "Human metapneumovirus pneumonia",
"J128": "Other viral pneumonia",
"J1281": "Pneumonia due to SARS-associated coronavirus",
"J1282": "Pneumonia due to coronavirus disease 2019",
"J1289": "Other viral pneumonia",
"J129": "Viral pneumonia, unspecified",
"J13": "Pneumonia due to Streptococcus pneumoniae",
"J14": "Pneumonia due to Hemophilus influenzae",
"J15": "Bacterial pneumonia, not elsewhere classified",
share/icd10.json view on Meta::CPAN
"Q240": "Dextrocardia",
"Q241": "Levocardia",
"Q242": "Cor triatriatum",
"Q243": "Pulmonary infundibular stenosis",
"Q244": "Congenital subaortic stenosis",
"Q245": "Malformation of coronary vessels",
"Q246": "Congenital heart block",
"Q248": "Other specified congenital malformations of heart",
"Q249": "Congenital malformation of heart, unspecified",
"Q25": "Congenital malformations of great arteries",
"Q250": "Patent ductus arteriosus",
share/icd10.json view on Meta::CPAN
"R92342": "Mammographic extreme density, left breast",
"R92343": "Mammographic extreme density, bilateral breasts",
"R928": "Other abnormal and inconclusive findings on diagnostic imaging of breast",
"R93": "Abnormal findings on diagnostic imaging of other body structures",
"R930": "Abnormal findings on diagnostic imaging of skull and head, not elsewhere classified",
"R931": "Abnormal findings on diagnostic imaging of heart and coronary circulation",
"R932": "Abnormal findings on diagnostic imaging of liver and biliary tract",
"R933": "Abnormal findings on diagnostic imaging of other parts of digestive tract",
"R934": "Abnormal findings on diagnostic imaging of urinary organs",
"R9341": "Abnormal radiologic findings on diagnostic imaging of renal pelvis, ureter, or bladder",
"R9342": "Abnormal radiologic findings on diagnostic imaging of kidney",
share/icd10.json view on Meta::CPAN
"S02612": "Fracture of condylar process of left mandible",
"S0262": "Fracture of subcondylar process of mandible",
"S02620": "Fracture of subcondylar process of mandible, unspecified side",
"S02621": "Fracture of subcondylar process of right mandible",
"S02622": "Fracture of subcondylar process of left mandible",
"S0263": "Fracture of coronoid process of mandible",
"S02630": "Fracture of coronoid process of mandible, unspecified side",
"S02631": "Fracture of coronoid process of right mandible",
"S02632": "Fracture of coronoid process of left mandible",
"S0264": "Fracture of ramus of mandible",
"S02640": "Fracture of ramus of mandible, unspecified side",
"S02641": "Fracture of ramus of right mandible",
"S02642": "Fracture of ramus of left mandible",
"S0265": "Fracture of angle of mandible",
share/icd10.json view on Meta::CPAN
"S52032": "Displaced fracture of olecranon process with intraarticular extension of left ulna",
"S52033": "Displaced fracture of olecranon process with intraarticular extension of unspecified ulna",
"S52034": "Nondisplaced fracture of olecranon process with intraarticular extension of right ulna",
"S52035": "Nondisplaced fracture of olecranon process with intraarticular extension of left ulna",
"S52036": "Nondisplaced fracture of olecranon process with intraarticular extension of unspecified ulna",
"S5204": "Fracture of coronoid process of ulna",
"S52041": "Displaced fracture of coronoid process of right ulna",
"S52042": "Displaced fracture of coronoid process of left ulna",
"S52043": "Displaced fracture of coronoid process of unspecified ulna",
"S52044": "Nondisplaced fracture of coronoid process of right ulna",
"S52045": "Nondisplaced fracture of coronoid process of left ulna",
"S52046": "Nondisplaced fracture of coronoid process of unspecified ulna",
"S5209": "Other fracture of upper end of ulna",
"S52091": "Other fracture of upper end of right ulna",
"S52092": "Other fracture of upper end of left ulna",
"S52099": "Other fracture of upper end of unspecified ulna",
"S521": "Fracture of upper end of radius",
share/icd10.json view on Meta::CPAN
"T462X2": "Poisoning by other antidysrhythmic drugs, intentional self-harm",
"T462X3": "Poisoning by other antidysrhythmic drugs, assault",
"T462X4": "Poisoning by other antidysrhythmic drugs, undetermined",
"T462X5": "Adverse effect of other antidysrhythmic drugs",
"T462X6": "Underdosing of other antidysrhythmic drugs",
"T463": "Poisoning by, adverse effect of and underdosing of coronary vasodilators",
"T463X": "Poisoning by, adverse effect of and underdosing of coronary vasodilators",
"T463X1": "Poisoning by coronary vasodilators, accidental (unintentional)",
"T463X2": "Poisoning by coronary vasodilators, intentional self-harm",
"T463X3": "Poisoning by coronary vasodilators, assault",
"T463X4": "Poisoning by coronary vasodilators, undetermined",
"T463X5": "Adverse effect of coronary vasodilators",
"T463X6": "Underdosing of coronary vasodilators",
"T464": "Poisoning by, adverse effect of and underdosing of angiotensin-converting-enzyme inhibitors",
"T464X": "Poisoning by, adverse effect of and underdosing of angiotensin-converting-enzyme inhibitors",
"T464X1": "Poisoning by angiotensin-converting-enzyme inhibitors, accidental (unintentional)",
"T464X2": "Poisoning by angiotensin-converting-enzyme inhibitors, intentional self-harm",
"T464X3": "Poisoning by angiotensin-converting-enzyme inhibitors, assault",
share/icd10.json view on Meta::CPAN
"T8219": "Other mechanical complication of cardiac electronic device",
"T82190": "Other mechanical complication of cardiac electrode",
"T82191": "Other mechanical complication of cardiac pulse generator (battery)",
"T82198": "Other mechanical complication of other cardiac electronic device",
"T82199": "Other mechanical complication of unspecified cardiac device",
"T822": "Mechanical complication of coronary artery bypass graft and biological heart valve graft",
"T8221": "Mechanical complication of coronary artery bypass graft",
"T82211": "Breakdown (mechanical) of coronary artery bypass graft",
"T82212": "Displacement of coronary artery bypass graft",
"T82213": "Leakage of coronary artery bypass graft",
"T82218": "Other mechanical complication of coronary artery bypass graft",
"T8222": "Mechanical complication of biological heart valve graft",
"T82221": "Breakdown (mechanical) of biological heart valve graft",
"T82222": "Displacement of biological heart valve graft",
"T82223": "Leakage of biological heart valve graft",
"T82228": "Other mechanical complication of biological heart valve graft",
share/icd10.json view on Meta::CPAN
"T82838": "Hemorrhage due to vascular prosthetic devices, implants and grafts",
"T8284": "Pain due to cardiac and vascular prosthetic devices, implants and grafts",
"T82847": "Pain due to cardiac prosthetic devices, implants and grafts",
"T82848": "Pain due to vascular prosthetic devices, implants and grafts",
"T8285": "Stenosis due to cardiac and vascular prosthetic devices, implants and grafts",
"T82855": "Stenosis of coronary artery stent",
"T82856": "Stenosis of peripheral vascular stent",
"T82857": "Stenosis of other cardiac prosthetic devices, implants and grafts",
"T82858": "Stenosis of other vascular prosthetic devices, implants and grafts",
"T8286": "Thrombosis of cardiac and vascular prosthetic devices, implants and grafts",
"T82867": "Thrombosis due to cardiac prosthetic devices, implants and grafts",
share/icd10.json view on Meta::CPAN
"Z9484": "Stem cells transplant status",
"Z9489": "Other transplanted organ and tissue status",
"Z949": "Transplanted organ and tissue status, unspecified",
"Z95": "Presence of cardiac and vascular implants and grafts",
"Z950": "Presence of cardiac pacemaker",
"Z951": "Presence of aortocoronary bypass graft",
"Z952": "Presence of prosthetic heart valve",
"Z953": "Presence of xenogenic heart valve",
"Z954": "Presence of other heart-valve replacement",
"Z955": "Presence of coronary angioplasty implant and graft",
"Z958": "Presence of other cardiac and vascular implants and grafts",
"Z9581": "Presence of other cardiac implants and grafts",
"Z95810": "Presence of automatic (implantable) cardiac defibrillator",
"Z95811": "Presence of heart assist device",
"Z95812": "Presence of fully implantable artificial heart",
ClearCase-CRDB
view release on metacpan or search on metacpan
MINUSES
* A true code analysis tool must have knowledge of each programming
language in use. I.e. to add support for Java, a Java parser must be
added.
* A corollary of the above is that it requires lot of work by expert
programmers. Thus the tools tend to be large, complex and expensive.
Note: there is also *cscope* which is free, and maybe others. But as
the name implies *cscope* is limited to C-like languages.
* Another corollary is that the tool must track each advance in each
language, usually with significant lag time, and may not be
bug-for-bug compatible with the compiler.
* Also, since analysis basically entails compiling the code, analysis
of a large code base can take a long time, potentially as long or
ClearCase-Wrapper
view release on metacpan or search on metacpan
As well as allowing for site-wide enhancements to be made in
Wrapper.pm, a hook is also provided for individual users to set their
own defaults. If the file C<~/.clearcase_profile.pl> exists it will be
read before launching any of the sitewide enhancements. Note that this
file is passed to the Perl interpreter and thus has access to the full
array of Perl syntax. This mechanism is powerful but the corollary is
that users must be experienced with both ClearCase and Perl, and to
some degree with the ClearCase::Wrapper module, to use it. Here's an
example:
% cat ~/.clearcase_profile.pl
CljPerl
view release on metacpan or search on metacpan
lib/CljPerl/Evaler.pm view on Meta::CPAN
"or"=>1,
"equal"=>1,
"require"=>1,
"read"=>1,
"println"=>1,
"coro"=>1,
"coro-suspend"=>1,
"coro-sleep"=>1,
"coro-yield"=>1,
"coro-resume"=>1,
"coro-wake"=>1,
"coro-join"=>1,
"coro-current"=>1,
"coro-main"=>1,
"xml-name"=>1,
"trace-vars"=>1};
our $empty_list = CljPerl::Seq->new("list");
our $true = CljPerl::Atom->new("bool", "true");
lib/CljPerl/Evaler.pm view on Meta::CPAN
# (println obj)
} elsif($fn eq "println") {
$ast->error("println expects 1 argument") if $size != 2;
print CljPerl::Printer::to_string($self->_eval($ast->second())) . "\n";
return $nil;
} elsif($fn eq "coro") {
$ast->error("coro expects 1 argument") if $size != 2;
my $b = $self->_eval($ast->second());
$ast->error("core expects a function as argument but got " . $b->type()) if $b->type() ne "function";
my $coro = new Coro sub {
my $evaler = CljPerl::Evaler->new();
my $fc = CljPerl::Seq->new("list");
$fc->append($b);
$evaler->_eval($fc);
};
$coro->ready();
return CljPerl::Atom->new("coroutine", $coro);
} elsif($fn eq "coro-suspend") {
$ast->error("coro-suspend expects 1 argument") if $size != 2;
my $coro = $self->_eval($ast->second());
$ast->error("coro-suspend expects a coroutine as argument but got " . $coro->type()) if $coro->type() ne "coroutine";
$coro->value()->suspend();
return $coro;
} elsif($fn eq "coro-sleep") {
$ast->error("coro-sleep expects 0 argument") if $size != 1;
$Coro::current->suspend();
cede;
return CljPerl::Atom->new("coroutine", $Coro::current);
} elsif($fn eq "coro-yield") {
$ast->error("coro-yield expects 0 argument") if $size != 1;
cede;
return CljPerl::Atom->new("coroutine", $Coro::current);
} elsif($fn eq "coro-resume") {
$ast->error("coro-resume expects 1 argument") if $size != 2;
my $coro = $self->_eval($ast->second());
$ast->error("coro-resume expects a coroutine as argument but got " . $coro->type()) if $coro->type() ne "coroutine";
$coro->value()->resume();
$coro->value()->cede_to();
return $coro;
} elsif($fn eq "coro-wake") {
$ast->error("coro-wake expects 1 argument") if $size != 2;
my $coro = $self->_eval($ast->second());
$ast->error("coro-wake expects a coroutine as argument but got " . $coro->type()) if $coro->type() ne "coroutine";
$coro->value()->resume();
return $coro;
} elsif($fn eq "join-coro") {
$ast->error("join-coro expects 1 argument") if $size != 2;
my $coro = $self->_eval($ast->second());
$ast->error("join-coro expects a coroutine as argument but got " . $coro->type()) if $coro->type() ne "coroutine";
$coro->value()->join();
return $coro;
} elsif($fn eq "coro-current") {
$ast->error("coro-current expects 0 argument") if $size != 1;
return CljPerl::Atom->new("coroutine", $Coro::current);
} elsif($fn eq "coro-main") {
$ast->error("coro-main expects 0 argument") if $size != 1;
return CljPerl::Atom->new("coroutine", $Coro::main);
} elsif($fn eq "trace-vars") {
$ast->error("trace-vars expects 0 argument") if $size != 1;
$self->trace_vars();
return $nil;
};
Color-Library
view release on metacpan or search on metacpan
lib/Color/Library/Dictionary/NBS_ISCC/M.pm view on Meta::CPAN
cornhusk cornhusk #c19a6b
cornsilk cornsilk #f8de7e
coromandel coromandel #79443b
coronation coronation #5d3954
coronation coronation #673147
corsage green corsagegreen #6aab8e
corsage green corsagegreen #66ada4
lib/Color/Library/Dictionary/NBS_ISCC/M.pm view on Meta::CPAN
['nbs-iscc-m:cornelianred.39','cornelianred','cornelian red',[180,116,94],'b4745e',11826270],
['nbs-iscc-m:cornflowerblue.200','cornflowerblue','cornflower [blue] ',[78,81,128],'4e5180',5132672],
['nbs-iscc-m:cornhusk.73','cornhusk','cornhusk',[250,214,165],'fad6a5',16438949],
['nbs-iscc-m:cornhusk.76','cornhusk','cornhusk',[193,154,107],'c19a6b',12687979],
['nbs-iscc-m:cornsilk.86','cornsilk','cornsilk',[248,222,126],'f8de7e',16309886],
['nbs-iscc-m:coromandel.43','coromandel','coromandel',[121,68,59],'79443b',7947323],
['nbs-iscc-m:coronation.242','coronation','coronation',[93,57,84],'5d3954',6109524],
['nbs-iscc-m:coronation.259','coronation','coronation',[103,49,71],'673147',6762823],
['nbs-iscc-m:corsagegreen.144','corsagegreen','corsage green',[106,171,142],'6aab8e',6990734],
['nbs-iscc-m:corsagegreen.163','corsagegreen','corsage green',[102,173,164],'66ada4',6729124],
['nbs-iscc-m:corsair.183','corsair','corsair',[0,48,78],'00304e',12366],
['nbs-iscc-m:corsicanblue.200','corsicanblue','corsican blue',[78,81,128],'4e5180',5132672],
['nbs-iscc-m:corsicanblue.201','corsicanblue','corsican blue',[37,36,64],'252440',2434112],
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
t/omop2bff/out/individuals_csv.json
t/omop2bff/out/individuals_csv.json.gz
t/omop2bff/out/individuals_drug_exposure.json.gz
t/omop2bff/out/ohdsi.json
t/omop2pxf/out/pxf.json
t/openehr2bff/in/compo_corona.json
t/openehr2bff/in/gecco_personendaten.json
t/openehr2bff/in/gecco_personendaten_patient.json
t/openehr2bff/in/ips_canonical.json
t/openehr2bff/in/laboratory_report.json
t/openehr2bff/in/README.md
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).
( run in 0.919 second using v1.01-cache-2.11-cpan-39bf76dae61 )