| … | |
… | |
| 671 | returning a new coderef. Unblocking means that calling the new coderef |
671 | returning a new coderef. Unblocking means that calling the new coderef |
| 672 | will return immediately without blocking, returning nothing, while the |
672 | will return immediately without blocking, returning nothing, while the |
| 673 | original code ref will be called (with parameters) from within another |
673 | original code ref will be called (with parameters) from within another |
| 674 | coro. |
674 | coro. |
| 675 | |
675 | |
| 676 | 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 |
| 677 | 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 |
| 678 | of reentrancy). This means you must not block within event callbacks, |
678 | of reentrancy). This means you must not block within event callbacks, |
| 679 | 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 |
| 680 | 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). |
| 681 | |
682 | |
| 682 | 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 |
| 683 | ("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 |
| 684 | only works when you do not run your own event loop. |
685 | only works when you do not run your own event loop. |
| 685 | |
686 | |
| … | |
… | |
| 868 | 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 |
| 869 | 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, |
| 870 | it is probably not obvious to everybody). |
871 | it is probably not obvious to everybody). |
| 871 | |
872 | |
| 872 | 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 |
| 873 | scripting languages given onthe perl workshop 2009: |
874 | scripting languages given on the perl workshop 2009: |
| 874 | |
875 | |
| 875 | The so-called "ithreads" were originally implemented for two reasons: |
876 | The so-called "ithreads" were originally implemented for two reasons: |
| 876 | first, to (badly) emulate unix processes on native win32 perls, and |
877 | first, to (badly) emulate unix processes on native win32 perls, and |
| 877 | secondly, to replace the older, real thread model ("5.005-threads"). |
878 | secondly, to replace the older, real thread model ("5.005-threads"). |
| 878 | |
879 | |
