… | |
… | |
35 | parallel access are rarely an issue, making coroutine programming much |
35 | parallel access are rarely an issue, making coroutine programming much |
36 | safer and easier than threads programming. |
36 | safer and easier than threads programming. |
37 | |
37 | |
38 | Unlike a normal perl program, however, coroutines allow you to have |
38 | Unlike a normal perl program, however, coroutines allow you to have |
39 | multiple running interpreters that share data, which is especially useful |
39 | multiple running interpreters that share data, which is especially useful |
40 | to code pseudo-parallel processes, such as multiple HTTP-GET requests |
40 | to code pseudo-parallel processes and for event-based programming, such as |
41 | running concurrently. |
41 | multiple HTTP-GET requests running concurrently. See L<Coro::AnyEvent> to |
|
|
42 | learn more. |
42 | |
43 | |
43 | Coroutines are also useful because Perl has no support for threads (the so |
44 | Coroutines are also useful because Perl has no support for threads (the so |
44 | called "threads" that perl offers are nothing more than the (bad) process |
45 | called "threads" that perl offers are nothing more than the (bad) process |
45 | emulation coming from the Windows platform: On standard operating systems |
46 | emulation coming from the Windows platform: On standard operating systems |
46 | they serve no purpose whatsoever, except by making your programs slow and |
47 | they serve no purpose whatsoever, except by making your programs slow and |
… | |
… | |
65 | |
66 | |
66 | our $idle; # idle handler |
67 | our $idle; # idle handler |
67 | our $main; # main coroutine |
68 | our $main; # main coroutine |
68 | our $current; # current coroutine |
69 | our $current; # current coroutine |
69 | |
70 | |
70 | our $VERSION = 4.6; |
71 | our $VERSION = 4.741; |
71 | |
72 | |
72 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); |
73 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); |
73 | our %EXPORT_TAGS = ( |
74 | our %EXPORT_TAGS = ( |
74 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
75 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
75 | ); |
76 | ); |
… | |
… | |
611 | |
612 | |
612 | If your handler does not plan to block (e.g. simply sends a message to |
613 | If your handler does not plan to block (e.g. simply sends a message to |
613 | another coroutine, or puts some other coroutine into the ready queue), |
614 | another coroutine, or puts some other coroutine into the ready queue), |
614 | there is no reason to use C<unblock_sub>. |
615 | there is no reason to use C<unblock_sub>. |
615 | |
616 | |
|
|
617 | Note that you also need to use C<unblock_sub> for any other callbacks that |
|
|
618 | are indirectly executed by any C-based event loop. For example, when you |
|
|
619 | use a module that uses L<AnyEvent> (and you use L<Coro::AnyEvent>) and it |
|
|
620 | provides callbacks that are the result of some event callback, then you |
|
|
621 | must not block either, or use C<unblock_sub>. |
|
|
622 | |
616 | =cut |
623 | =cut |
617 | |
624 | |
618 | our @unblock_queue; |
625 | our @unblock_queue; |
619 | |
626 | |
620 | # we create a special coro because we want to cede, |
627 | # we create a special coro because we want to cede, |