ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/Coro/Coro.pm
(Generate patch)

Comparing Coro/Coro.pm (file contents):
Revision 1.331 by root, Thu Jun 4 22:58:28 2015 UTC vs.
Revision 1.349 by root, Tue Aug 14 16:51:37 2018 UTC

366 366
367our $idle; # idle handler 367our $idle; # idle handler
368our $main; # main coro 368our $main; # main coro
369our $current; # current coro 369our $current; # current coro
370 370
371our $VERSION = 6.43; 371our $VERSION = 6.52;
372 372
373our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub rouse_cb rouse_wait); 373our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub rouse_cb rouse_wait);
374our %EXPORT_TAGS = ( 374our %EXPORT_TAGS = (
375 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], 375 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
376); 376);
498C<async> does. As the coro is being reused, stuff like C<on_destroy> 498C<async> does. As the coro is being reused, stuff like C<on_destroy>
499will not work in the expected way, unless you call terminate or cancel, 499will not work in the expected way, unless you call terminate or cancel,
500which somehow defeats the purpose of pooling (but is fine in the 500which somehow defeats the purpose of pooling (but is fine in the
501exceptional case). 501exceptional case).
502 502
503The priority will be reset to C<0> after each run, tracing will be 503The priority will be reset to C<0> after each run, all C<swap_sv> calls
504disabled, the description will be reset and the default output filehandle 504will be undone, tracing will be disabled, the description will be reset
505gets restored, so you can change all these. Otherwise the coro will 505and the default output filehandle gets restored, so you can change all
506be re-used "as-is": most notably if you change other per-coro global 506these. Otherwise the coro will be re-used "as-is": most notably if you
507stuff such as C<$/> you I<must needs> revert that change, which is most 507change other per-coro global stuff such as C<$/> you I<must needs> revert
508simply done by using local as in: C<< local $/ >>. 508that change, which is most simply done by using local as in: C<< local $/
509>>.
509 510
510The idle pool size is limited to C<8> idle coros (this can be 511The idle pool size is limited to C<8> idle coros (this can be
511adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle 512adjusted by changing $Coro::POOL_SIZE), but there can be as many non-idle
512coros as required. 513coros as required.
513 514
637 # at this place, the timezone is Antarctica/South_Pole, 638 # at this place, the timezone is Antarctica/South_Pole,
638 # without disturbing the TZ of any other coro. 639 # without disturbing the TZ of any other coro.
639 }; 640 };
640 641
641This can be used to localise about any resource (locale, uid, current 642This can be used to localise about any resource (locale, uid, current
642working directory etc.) to a block, despite the existance of other 643working directory etc.) to a block, despite the existence of other
643coros. 644coros.
644 645
645Another interesting example implements time-sliced multitasking using 646Another interesting example implements time-sliced multitasking using
646interval timers (this could obviously be optimised, but does the job): 647interval timers (this could obviously be optimised, but does the job):
647 648
753=item $state->is_new 754=item $state->is_new
754 755
755Returns true iff this Coro object is "new", i.e. has never been run 756Returns true iff this Coro object is "new", i.e. has never been run
756yet. Those states basically consist of only the code reference to call and 757yet. Those states basically consist of only the code reference to call and
757the arguments, but consumes very little other resources. New states will 758the arguments, but consumes very little other resources. New states will
758automatically get assigned a perl interpreter when they are transfered to. 759automatically get assigned a perl interpreter when they are transferred to.
759 760
760=item $state->is_zombie 761=item $state->is_zombie
761 762
762Returns true iff the Coro object has been cancelled, i.e. 763Returns true iff the Coro object has been cancelled, i.e.
763it's resources freed because they were C<cancel>'ed, C<terminate>'d, 764it's resources freed because they were C<cancel>'ed, C<terminate>'d,
781=item $is_suspended = $coro->is_suspended 782=item $is_suspended = $coro->is_suspended
782 783
783Returns true iff this Coro object has been suspended. Suspended Coros will 784Returns true iff this Coro object has been suspended. Suspended Coros will
784not ever be scheduled. 785not ever be scheduled.
785 786
786=item $coro->cancel (arg...) 787=item $coro->cancel ($arg...)
787 788
788Terminates the given Coro thread and makes it return the given arguments as 789Terminate the given Coro thread and make it return the given arguments as
789status (default: an empty list). Never returns if the Coro is the 790status (default: an empty list). Never returns if the Coro is the
790current Coro. 791current Coro.
791 792
792This is a rather brutal way to free a coro, with some limitations - if 793This is a rather brutal way to free a coro, with some limitations - if
793the thread is inside a C callback that doesn't expect to be canceled, 794the thread is inside a C callback that doesn't expect to be canceled,
829context and can block if they wish. The downside is that there is no 830context and can block if they wish. The downside is that there is no
830guarantee that the thread can be cancelled when you call this method, and 831guarantee that the thread can be cancelled when you call this method, and
831therefore, it might fail. It is also considerably slower than C<cancel> or 832therefore, it might fail. It is also considerably slower than C<cancel> or
832C<terminate>. 833C<terminate>.
833 834
834A thread is in a safe-cancellable state if it either hasn't been run yet, 835A thread is in a safe-cancellable state if it either has never been run
836yet, has already been canceled/terminated or otherwise destroyed, or has
835or it has no C context attached and is inside an SLF function. 837no C context attached and is inside an SLF function.
836 838
839The first two states are trivial - a thread that hasnot started or has
840already finished is safe to cancel.
841
837The latter two basically mean that the thread isn't currently inside a 842The last state basically means that the thread isn't currently inside a
838perl callback called from some C function (usually via some XS modules) 843perl callback called from some C function (usually via some XS modules)
839and isn't currently executing inside some C function itself (via Coro's XS 844and isn't currently executing inside some C function itself (via Coro's XS
840API). 845API).
841 846
842This call returns true when it could cancel the thread, or croaks with an 847This call returns true when it could cancel the thread, or croaks with an
1122It is very common for a coro to wait for some callback to be 1127It is very common for a coro to wait for some callback to be
1123called. This occurs naturally when you use coro in an otherwise 1128called. This occurs naturally when you use coro in an otherwise
1124event-based program, or when you use event-based libraries. 1129event-based program, or when you use event-based libraries.
1125 1130
1126These typically register a callback for some event, and call that callback 1131These typically register a callback for some event, and call that callback
1127when the event occured. In a coro, however, you typically want to 1132when the event occurred. In a coro, however, you typically want to
1128just wait for the event, simplyifying things. 1133just wait for the event, simplyifying things.
1129 1134
1130For example C<< AnyEvent->child >> registers a callback to be called when 1135For example C<< AnyEvent->child >> registers a callback to be called when
1131a specific child has exited: 1136a specific child has exited:
1132 1137
1261processes. What makes it so bad is that on non-windows platforms, you can 1266processes. What makes it so bad is that on non-windows platforms, you can
1262actually take advantage of custom hardware for this purpose (as evidenced 1267actually take advantage of custom hardware for this purpose (as evidenced
1263by the forks module, which gives you the (i-) threads API, just much 1268by the forks module, which gives you the (i-) threads API, just much
1264faster). 1269faster).
1265 1270
1266Sharing data is in the i-threads model is done by transfering data 1271Sharing data is in the i-threads model is done by transferring data
1267structures between threads using copying semantics, which is very slow - 1272structures between threads using copying semantics, which is very slow -
1268shared data simply does not exist. Benchmarks using i-threads which are 1273shared data simply does not exist. Benchmarks using i-threads which are
1269communication-intensive show extremely bad behaviour with i-threads (in 1274communication-intensive show extremely bad behaviour with i-threads (in
1270fact, so bad that Coro, which cannot take direct advantage of multiple 1275fact, so bad that Coro, which cannot take direct advantage of multiple
1271CPUs, is often orders of magnitude faster because it shares data using 1276CPUs, is often orders of magnitude faster because it shares data using
1301 1306
1302XS API: L<Coro::MakeMaker>. 1307XS API: L<Coro::MakeMaker>.
1303 1308
1304Low level Configuration, Thread Environment, Continuations: L<Coro::State>. 1309Low level Configuration, Thread Environment, Continuations: L<Coro::State>.
1305 1310
1306=head1 AUTHOR 1311=head1 AUTHOR/SUPPORT/CONTACT
1307 1312
1308 Marc Lehmann <schmorp@schmorp.de> 1313 Marc A. Lehmann <schmorp@schmorp.de>
1309 http://home.schmorp.de/ 1314 http://software.schmorp.de/pkg/Coro.html
1310 1315
1311=cut 1316=cut
1312 1317

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines