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

Comparing cvsroot/Coro/Coro.pm (file contents):
Revision 1.237 by root, Sat Nov 22 16:37:11 2008 UTC vs.
Revision 1.247 by root, Mon Dec 15 02:07:11 2008 UTC

1=head1 NAME 1=head1 NAME
2 2
3Coro - real threads in perl 3Coro - the only real threads in perl
4 4
5=head1 SYNOPSIS 5=head1 SYNOPSIS
6 6
7 use Coro; 7 use Coro;
8 8
29=head1 DESCRIPTION 29=head1 DESCRIPTION
30 30
31For a tutorial-style introduction, please read the L<Coro::Intro> 31For a tutorial-style introduction, please read the L<Coro::Intro>
32manpage. This manpage mainly contains reference information. 32manpage. This manpage mainly contains reference information.
33 33
34This module collection manages coroutines, that is, cooperative 34This module collection manages continuations in general, most often
35threads. Coroutines are similar to kernel threads but don't (in general) 35in the form of cooperative threads (also called coroutines in the
36documentation). They are similar to kernel threads but don't (in general)
36run in parallel at the same time even on SMP machines. The specific flavor 37run in parallel at the same time even on SMP machines. The specific flavor
37of coroutine used in this module also guarantees you that it will not 38of thread offered by this module also guarantees you that it will not
38switch between coroutines unless necessary, at easily-identified points 39switch between threads unless necessary, at easily-identified points in
39in your program, so locking and parallel access are rarely an issue, 40your program, so locking and parallel access are rarely an issue, making
40making coroutine programming much safer and easier than using other thread 41thread programming much safer and easier than using other thread models.
41models.
42 42
43Unlike the so-called "Perl threads" (which are not actually real threads 43Unlike the so-called "Perl threads" (which are not actually real threads
44but only the windows process emulation ported to unix), Coro provides a 44but only the windows process emulation ported to unix), Coro provides a
45full shared address space, which makes communication between coroutines 45full shared address space, which makes communication between threads
46very easy. And coroutines are fast, too: disabling the Windows process 46very easy. And threads are fast, too: disabling the Windows process
47emulation code in your perl and using Coro can easily result in a two to 47emulation code in your perl and using Coro can easily result in a two to
48four times speed increase for your programs. 48four times speed increase for your programs.
49 49
50Coro achieves that by supporting multiple running interpreters that share 50Coro achieves that by supporting multiple running interpreters that share
51data, which is especially useful to code pseudo-parallel processes and 51data, which is especially useful to code pseudo-parallel processes and
52for event-based programming, such as multiple HTTP-GET requests running 52for event-based programming, such as multiple HTTP-GET requests running
53concurrently. See L<Coro::AnyEvent> to learn more on how to integrate Coro 53concurrently. See L<Coro::AnyEvent> to learn more on how to integrate Coro
54into an event-based environment. 54into an event-based environment.
55 55
56In this module, a coroutines is defined as "callchain + lexical variables 56In this module, a thread is defined as "callchain + lexical variables +
57+ @_ + $_ + $@ + $/ + C stack), that is, a coroutine has its own 57@_ + $_ + $@ + $/ + C stack), that is, a thread has its own callchain,
58callchain, its own set of lexicals and its own set of perls most important 58its own set of lexicals and its own set of perls most important global
59global variables (see L<Coro::State> for more configuration and background 59variables (see L<Coro::State> for more configuration and background info).
60info).
61 60
62See also the C<SEE ALSO> section at the end of this document - the Coro 61See also the C<SEE ALSO> section at the end of this document - the Coro
63module family is quite large. 62module family is quite large.
64 63
65=cut 64=cut
66 65
67package Coro; 66package Coro;
68 67
69use strict qw(vars subs); 68use strict qw(vars subs);
70no warnings "uninitialized"; 69no warnings "uninitialized";
70
71use Guard ();
71 72
72use Coro::State; 73use Coro::State;
73 74
74use base qw(Coro::State Exporter); 75use base qw(Coro::State Exporter);
75 76
76our $idle; # idle handler 77our $idle; # idle handler
77our $main; # main coroutine 78our $main; # main coroutine
78our $current; # current coroutine 79our $current; # current coroutine
79 80
80our $VERSION = "5.0"; 81our $VERSION = 5.13;
81 82
82our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); 83our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub);
83our %EXPORT_TAGS = ( 84our %EXPORT_TAGS = (
84 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], 85 prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)],
85); 86);
115sub current() { $current } # [DEPRECATED] 116sub current() { $current } # [DEPRECATED]
116 117
117=item $Coro::idle 118=item $Coro::idle
118 119
119This variable is mainly useful to integrate Coro into event loops. It is 120This variable is mainly useful to integrate Coro into event loops. It is
120usually better to rely on L<Coro::AnyEvent> or LC<Coro::EV>, as this is 121usually better to rely on L<Coro::AnyEvent> or L<Coro::EV>, as this is
121pretty low-level functionality. 122pretty low-level functionality.
122 123
123This variable stores a callback that is called whenever the scheduler 124This variable stores either a coroutine or a callback.
125
126If it is a callback, the it is called whenever the scheduler finds no
124finds no ready coroutines to run. The default implementation prints 127ready coroutines to run. The default implementation prints "FATAL:
125"FATAL: deadlock detected" and exits, because the program has no other way 128deadlock detected" and exits, because the program has no other way to
126to continue. 129continue.
127 130
131If it is a coroutine object, then this object will be readied (without
132invoking any ready hooks, however) when the scheduler finds no other ready
133coroutines to run.
134
128This hook is overwritten by modules such as C<Coro::Timer> and 135This hook is overwritten by modules such as C<Coro::EV> and
129C<Coro::AnyEvent> to wait on an external event that hopefully wake up a 136C<Coro::AnyEvent> to wait on an external event that hopefully wake up a
130coroutine so the scheduler can run it. 137coroutine so the scheduler can run it.
131 138
132Note that the callback I<must not>, under any circumstances, block 139Note that the callback I<must not>, under any circumstances, block
133the current coroutine. Normally, this is achieved by having an "idle 140the current coroutine. Normally, this is achieved by having an "idle
134coroutine" that calls the event loop and then blocks again, and then 141coroutine" that calls the event loop and then blocks again, and then
135readying that coroutine in the idle handler. 142readying that coroutine in the idle handler, or by simply placing the idle
143coroutine in this variable.
136 144
137See L<Coro::Event> or L<Coro::AnyEvent> for examples of using this 145See L<Coro::Event> or L<Coro::AnyEvent> for examples of using this
138technique. 146technique.
139 147
140Please note that if your callback recursively invokes perl (e.g. for event 148Please note that if your callback recursively invokes perl (e.g. for event
169 177
170=over 4 178=over 4
171 179
172=item async { ... } [@args...] 180=item async { ... } [@args...]
173 181
174Create a new coroutine and return it's coroutine object (usually 182Create a new coroutine and return its coroutine object (usually
175unused). The coroutine will be put into the ready queue, so 183unused). The coroutine will be put into the ready queue, so
176it will start running automatically on the next scheduler run. 184it will start running automatically on the next scheduler run.
177 185
178The first argument is a codeblock/closure that should be executed in the 186The first argument is a codeblock/closure that should be executed in the
179coroutine. When it returns argument returns the coroutine is automatically 187coroutine. When it returns argument returns the coroutine is automatically
306 314
307=item terminate [arg...] 315=item terminate [arg...]
308 316
309Terminates the current coroutine with the given status values (see L<cancel>). 317Terminates the current coroutine with the given status values (see L<cancel>).
310 318
319=item Coro::on_enter BLOCK, Coro::on_leave BLOCK
320
321These function install enter and leave winders in the current scope. The
322enter block will be executed when on_enter is called and whenever the
323current coroutine is re-entered by the scheduler, while the leave block is
324executed whenever the current coroutine is blocked by the scheduler, and
325also when the containing scope is exited (by whatever means, be it exit,
326die, last etc.).
327
328I<Neither invoking the scheduler, nor exceptions, are allowed within those
329BLOCKs>. That means: do not even think about calling C<die> without an
330eval, and do not even think of entering the scheduler in any way.
331
332Since both BLOCKs are tied to the current scope, they will automatically
333be removed when the current scope exits.
334
335These functions implement the same concept as C<dynamic-wind> in scheme
336does, and are useful when you want to localise some resource to a specific
337coroutine.
338
339They slow down coroutine switching considerably for coroutines that use
340them (But coroutine switching is still reasonably fast if the handlers are
341fast).
342
343These functions are best understood by an example: The following function
344will change the current timezone to "Antarctica/South_Pole", which
345requires a call to C<tzset>, but by using C<on_enter> and C<on_leave>,
346which remember/change the current timezone and restore the previous
347value, respectively, the timezone is only changes for the coroutine that
348installed those handlers.
349
350 use POSIX qw(tzset);
351
352 async {
353 my $old_tz; # store outside TZ value here
354
355 Coro::on_enter {
356 $old_tz = $ENV{TZ}; # remember the old value
357
358 $ENV{TZ} = "Antarctica/South_Pole";
359 tzset; # enable new value
360 };
361
362 Coro::on_leave {
363 $ENV{TZ} = $old_tz;
364 tzset; # restore old value
365 };
366
367 # at this place, the timezone is Antarctica/South_Pole,
368 # without disturbing the TZ of any other coroutine.
369 };
370
371This can be used to localise about any resource (locale, uid, current
372working directory etc.) to a block, despite the existance of other
373coroutines.
374
311=item killall 375=item killall
312 376
313Kills/terminates/cancels all coroutines except the currently running 377Kills/terminates/cancels all coroutines except the currently running one.
314one. This is useful after a fork, either in the child or the parent, as
315usually only one of them should inherit the running coroutines.
316 378
317Note that while this will try to free some of the main programs resources, 379Note that while this will try to free some of the main interpreter
380resources if the calling coroutine isn't the main coroutine, but one
318you cannot free all of them, so if a coroutine that is not the main 381cannot free all of them, so if a coroutine that is not the main coroutine
319program calls this function, there will be some one-time resource leak. 382calls this function, there will be some one-time resource leak.
320 383
321=cut 384=cut
322 385
323sub killall { 386sub killall {
324 for (Coro::State::list) { 387 for (Coro::State::list) {
346See C<async> and C<Coro::State::new> for additional info about the 409See C<async> and C<Coro::State::new> for additional info about the
347coroutine environment. 410coroutine environment.
348 411
349=cut 412=cut
350 413
351sub _terminate { 414sub _coro_run {
352 terminate &{+shift}; 415 terminate &{+shift};
353} 416}
354 417
355=item $success = $coroutine->ready 418=item $success = $coroutine->ready
356 419
531would cause a deadlock unless there is an idle handler that wakes up some 594would cause a deadlock unless there is an idle handler that wakes up some
532coroutines. 595coroutines.
533 596
534=item my $guard = Coro::guard { ... } 597=item my $guard = Coro::guard { ... }
535 598
536This creates and returns a guard object. Nothing happens until the object 599This function still exists, but is deprecated. Please use the
537gets destroyed, in which case the codeblock given as argument will be 600C<Guard::guard> function instead.
538executed. This is useful to free locks or other resources in case of a
539runtime error or when the coroutine gets canceled, as in both cases the
540guard block will be executed. The guard object supports only one method,
541C<< ->cancel >>, which will keep the codeblock from being executed.
542 601
543Example: set some flag and clear it again when the coroutine gets canceled
544or the function returns:
545
546 sub do_something {
547 my $guard = Coro::guard { $busy = 0 };
548 $busy = 1;
549
550 # do something that requires $busy to be true
551 }
552
553=cut 602=cut
554 603
555sub guard(&) { 604BEGIN { *guard = \&Guard::guard }
556 bless \(my $cb = $_[0]), "Coro::guard"
557}
558
559sub Coro::guard::cancel {
560 ${$_[0]} = sub { };
561}
562
563sub Coro::guard::DESTROY {
564 ${$_[0]}->();
565}
566
567 605
568=item unblock_sub { ... } 606=item unblock_sub { ... }
569 607
570This utility function takes a BLOCK or code reference and "unblocks" it, 608This utility function takes a BLOCK or code reference and "unblocks" it,
571returning a new coderef. Unblocking means that calling the new coderef 609returning a new coderef. Unblocking means that calling the new coderef
573original code ref will be called (with parameters) from within another 611original code ref will be called (with parameters) from within another
574coroutine. 612coroutine.
575 613
576The reason this function exists is that many event libraries (such as the 614The reason this function exists is that many event libraries (such as the
577venerable L<Event|Event> module) are not coroutine-safe (a weaker form 615venerable L<Event|Event> module) are not coroutine-safe (a weaker form
578of thread-safety). This means you must not block within event callbacks, 616of reentrancy). This means you must not block within event callbacks,
579otherwise you might suffer from crashes or worse. The only event library 617otherwise you might suffer from crashes or worse. The only event library
580currently known that is safe to use without C<unblock_sub> is L<EV>. 618currently known that is safe to use without C<unblock_sub> is L<EV>.
581 619
582This function allows your callbacks to block by executing them in another 620This function allows your callbacks to block by executing them in another
583coroutine where it is safe to block. One example where blocking is handy 621coroutine where it is safe to block. One example where blocking is handy
629 } 667 }
630} 668}
631 669
632=item $cb = Coro::rouse_cb 670=item $cb = Coro::rouse_cb
633 671
634Create and return a "rouse callback". That's a code reference that, when 672Create and return a "rouse callback". That's a code reference that,
635called, will save its arguments and notify the owner coroutine of the 673when called, will remember a copy of its arguments and notify the owner
636callback. 674coroutine of the callback.
637 675
638See the next function. 676See the next function.
639 677
640=item @args = Coro::rouse_wait [$cb] 678=item @args = Coro::rouse_wait [$cb]
641 679
642Wait for the specified rouse callback (or the last one tht was created in 680Wait for the specified rouse callback (or the last one that was created in
643this coroutine). 681this coroutine).
644 682
645As soon as the callback is invoked (or when the calback was invoked before 683As soon as the callback is invoked (or when the callback was invoked
646C<rouse_wait>), it will return a copy of the arguments originally passed 684before C<rouse_wait>), it will return the arguments originally passed to
647to the rouse callback. 685the rouse callback.
648 686
649See the section B<HOW TO WAIT FOR A CALLBACK> for an actual usage example. 687See the section B<HOW TO WAIT FOR A CALLBACK> for an actual usage example.
650 688
651=back 689=back
652 690
675 713
676Coro offers two functions specifically designed to make this easy, 714Coro offers two functions specifically designed to make this easy,
677C<Coro::rouse_cb> and C<Coro::rouse_wait>. 715C<Coro::rouse_cb> and C<Coro::rouse_wait>.
678 716
679The first function, C<rouse_cb>, generates and returns a callback that, 717The first function, C<rouse_cb>, generates and returns a callback that,
680when invoked, will save it's arguments and notify the coroutine that 718when invoked, will save its arguments and notify the coroutine that
681created the callback. 719created the callback.
682 720
683The second function, C<rouse_wait>, waits for the callback to be called 721The second function, C<rouse_wait>, waits for the callback to be called
684(by calling C<schedule> to go to sleep) and returns the arguments 722(by calling C<schedule> to go to sleep) and returns the arguments
685originally passed to the callback. 723originally passed to the callback.
732fix your libc and use a saner backend. 770fix your libc and use a saner backend.
733 771
734=item perl process emulation ("threads") 772=item perl process emulation ("threads")
735 773
736This module is not perl-pseudo-thread-safe. You should only ever use this 774This module is not perl-pseudo-thread-safe. You should only ever use this
737module from the same thread (this requirement might be removed in the 775module from the first thread (this requirement might be removed in the
738future to allow per-thread schedulers, but Coro::State does not yet allow 776future to allow per-thread schedulers, but Coro::State does not yet allow
739this). I recommend disabling thread support and using processes, as having 777this). I recommend disabling thread support and using processes, as having
740the windows process emulation enabled under unix roughly halves perl 778the windows process emulation enabled under unix roughly halves perl
741performance, even when not used. 779performance, even when not used.
742 780
759 797
760Debugging: L<Coro::Debug>. 798Debugging: L<Coro::Debug>.
761 799
762Support/Utility: L<Coro::Specific>, L<Coro::Util>. 800Support/Utility: L<Coro::Specific>, L<Coro::Util>.
763 801
764Locking/IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>, 802Locking and IPC: L<Coro::Signal>, L<Coro::Channel>, L<Coro::Semaphore>,
765L<Coro::SemaphoreSet>, L<Coro::RWLock>. 803L<Coro::SemaphoreSet>, L<Coro::RWLock>.
766 804
767IO/Timers: L<Coro::Timer>, L<Coro::Handle>, L<Coro::Socket>, L<Coro::AIO>. 805I/O and Timers: L<Coro::Timer>, L<Coro::Handle>, L<Coro::Socket>, L<Coro::AIO>.
768 806
769Compatibility: L<Coro::LWP> (but see also L<AnyEvent::HTTP> for 807Compatibility with other modules: L<Coro::LWP> (but see also L<AnyEvent::HTTP> for
770a better-working alternative), L<Coro::BDB>, L<Coro::Storable>, 808a better-working alternative), L<Coro::BDB>, L<Coro::Storable>,
771L<Coro::Select>. 809L<Coro::Select>.
772 810
773XS API: L<Coro::MakeMaker>. 811XS API: L<Coro::MakeMaker>.
774 812
775Low level Configuration, Coroutine Environment: L<Coro::State>. 813Low level Configuration, Thread Environment, Continuations: L<Coro::State>.
776 814
777=head1 AUTHOR 815=head1 AUTHOR
778 816
779 Marc Lehmann <schmorp@schmorp.de> 817 Marc Lehmann <schmorp@schmorp.de>
780 http://home.schmorp.de/ 818 http://home.schmorp.de/

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines