… | |
… | |
81 | |
81 | |
82 | our $idle; # idle handler |
82 | our $idle; # idle handler |
83 | our $main; # main coro |
83 | our $main; # main coro |
84 | our $current; # current coro |
84 | our $current; # current coro |
85 | |
85 | |
86 | our $VERSION = 5.21; |
86 | our $VERSION = 5.25; |
87 | |
87 | |
88 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub rouse_cb rouse_wait); |
88 | our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub rouse_cb rouse_wait); |
89 | our %EXPORT_TAGS = ( |
89 | our %EXPORT_TAGS = ( |
90 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
90 | prio => [qw(PRIO_MAX PRIO_HIGH PRIO_NORMAL PRIO_LOW PRIO_IDLE PRIO_MIN)], |
91 | ); |
91 | ); |
… | |
… | |
613 | Sets (or gets in case the argument is missing) the description for this |
613 | Sets (or gets in case the argument is missing) the description for this |
614 | coro. This is just a free-form string you can associate with a |
614 | coro. This is just a free-form string you can associate with a |
615 | coro. |
615 | coro. |
616 | |
616 | |
617 | This method simply sets the C<< $coro->{desc} >> member to the given |
617 | This method simply sets the C<< $coro->{desc} >> member to the given |
618 | string. You can modify this member directly if you wish. |
618 | string. You can modify this member directly if you wish, and in fact, this |
|
|
619 | is often preferred to indicate major processing states that cna then be |
|
|
620 | seen for example in a L<Coro::Debug> session: |
|
|
621 | |
|
|
622 | sub my_long_function { |
|
|
623 | local $Coro::current->{desc} = "now in my_long_function"; |
|
|
624 | ... |
|
|
625 | $Coro::current->{desc} = "my_long_function: phase 1"; |
|
|
626 | ... |
|
|
627 | $Coro::current->{desc} = "my_long_function: phase 2"; |
|
|
628 | ... |
|
|
629 | } |
619 | |
630 | |
620 | =cut |
631 | =cut |
621 | |
632 | |
622 | sub desc { |
633 | sub desc { |
623 | my $old = $_[0]{desc}; |
634 | my $old = $_[0]{desc}; |
… | |
… | |
660 | returning a new coderef. Unblocking means that calling the new coderef |
671 | returning a new coderef. Unblocking means that calling the new coderef |
661 | will return immediately without blocking, returning nothing, while the |
672 | will return immediately without blocking, returning nothing, while the |
662 | original code ref will be called (with parameters) from within another |
673 | original code ref will be called (with parameters) from within another |
663 | coro. |
674 | coro. |
664 | |
675 | |
665 | The reason this function exists is that many event libraries (such as the |
676 | The reason this function exists is that many event libraries (such as |
666 | venerable L<Event|Event> module) are not thread-safe (a weaker form |
677 | the venerable L<Event|Event> module) are not thread-safe (a weaker form |
667 | of reentrancy). This means you must not block within event callbacks, |
678 | of reentrancy). This means you must not block within event callbacks, |
668 | otherwise you might suffer from crashes or worse. The only event library |
679 | otherwise you might suffer from crashes or worse. The only event library |
669 | currently known that is safe to use without C<unblock_sub> is L<EV>. |
680 | currently known that is safe to use without C<unblock_sub> is L<EV> (but |
|
|
681 | you might still run into deadlocks if all event loops are blocked). |
670 | |
682 | |
671 | Coro will try to catch you when you block in the event loop |
683 | Coro will try to catch you when you block in the event loop |
672 | ("FATAL:$Coro::IDLE blocked itself"), but this is just best effort and |
684 | ("FATAL:$Coro::IDLE blocked itself"), but this is just best effort and |
673 | only works when you do not run your own event loop. |
685 | only works when you do not run your own event loop. |
674 | |
686 | |
… | |
… | |
857 | ithreads (for example, that memory or files would be shared), showing his |
869 | ithreads (for example, that memory or files would be shared), showing his |
858 | lack of understanding of this area - if it is hard to understand for Chip, |
870 | lack of understanding of this area - if it is hard to understand for Chip, |
859 | it is probably not obvious to everybody). |
871 | it is probably not obvious to everybody). |
860 | |
872 | |
861 | What follows is an ultra-condensed version of my talk about threads in |
873 | What follows is an ultra-condensed version of my talk about threads in |
862 | scripting languages given onthe perl workshop 2009: |
874 | scripting languages given on the perl workshop 2009: |
863 | |
875 | |
864 | The so-called "ithreads" were originally implemented for two reasons: |
876 | The so-called "ithreads" were originally implemented for two reasons: |
865 | first, to (badly) emulate unix processes on native win32 perls, and |
877 | first, to (badly) emulate unix processes on native win32 perls, and |
866 | secondly, to replace the older, real thread model ("5.005-threads"). |
878 | secondly, to replace the older, real thread model ("5.005-threads"). |
867 | |
879 | |