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

Comparing Coro/Coro.pm (file contents):
Revision 1.263 by root, Tue Jul 28 02:04:21 2009 UTC vs.
Revision 1.268 by root, Thu Oct 1 23:16:27 2009 UTC

… …
40points in your program, so locking and parallel access are rarely an 40points in your program, so locking and parallel access are rarely an
41issue, making thread programming much safer and easier than using other 41issue, making thread programming much safer and easier than using other
42thread models. 42thread models.
43 43
44Unlike the so-called "Perl threads" (which are not actually real threads 44Unlike the so-called "Perl threads" (which are not actually real threads
45but only the windows process emulation ported to unix, and as such act 45but only the windows process emulation (see section of same name for more
46as processes), Coro provides a full shared address space, which makes 46details) ported to unix, and as such act as processes), Coro provides
47communication between threads very easy. And Coro's threads are fast, 47a full shared address space, which makes communication between threads
48too: disabling the Windows process emulation code in your perl and using 48very easy. And Coro's threads are fast, too: disabling the Windows
49Coro can easily result in a two to four times speed increase for your 49process emulation code in your perl and using Coro can easily result in
50programs. A parallel matrix multiplication benchmark runs over 300 times 50a two to four times speed increase for your programs. A parallel matrix
51faster on a single core than perl's pseudo-threads on a quad core using 51multiplication benchmark runs over 300 times faster on a single core than
52all four cores. 52perl's pseudo-threads on a quad core using all four cores.
53 53
54Coro achieves that by supporting multiple running interpreters that share 54Coro achieves that by supporting multiple running interpreters that share
55data, which is especially useful to code pseudo-parallel processes and 55data, which is especially useful to code pseudo-parallel processes and
56for event-based programming, such as multiple HTTP-GET requests running 56for event-based programming, such as multiple HTTP-GET requests running
57concurrently. See L<Coro::AnyEvent> to learn more on how to integrate Coro 57concurrently. See L<Coro::AnyEvent> to learn more on how to integrate Coro
… …
67 67
68=cut 68=cut
69 69
70package Coro; 70package Coro;
71 71
72use strict qw(vars subs); 72use common::sense;
73no warnings "uninitialized"; 73
74use Carp ();
74 75
75use Guard (); 76use Guard ();
76 77
77use Coro::State; 78use Coro::State;
78 79
… …
80 81
81our $idle; # idle handler 82our $idle; # idle handler
82our $main; # main coro 83our $main; # main coro
83our $current; # current coro 84our $current; # current coro
84 85
85our $VERSION = 5.162; 86our $VERSION = 5.17;
86 87
87our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub); 88our @EXPORT = qw(async async_pool cede schedule terminate current unblock_sub);
88our %EXPORT_TAGS = ( 89our %EXPORT_TAGS = (
89 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)],
90); 91);
… …
153handlers), then it must be prepared to be called recursively itself. 154handlers), then it must be prepared to be called recursively itself.
154 155
155=cut 156=cut
156 157
157$idle = sub { 158$idle = sub {
158 require Carp; 159 warn "oi\n";#d#
159 Carp::croak ("FATAL: deadlock detected"); 160 Carp::confess ("FATAL: deadlock detected");
160}; 161};
161 162
162# this coro is necessary because a coro 163# this coro is necessary because a coro
163# cannot destroy itself. 164# cannot destroy itself.
164our @destroy; 165our @destroy;
… …
206Example: Create a new coro that just prints its arguments. 207Example: Create a new coro that just prints its arguments.
207 208
208 async { 209 async {
209 print "@_\n"; 210 print "@_\n";
210 } 1,2,3,4; 211 } 1,2,3,4;
211
212=cut
213
214sub async(&@) {
215 my $coro = new Coro @_;
216 $coro->ready;
217 $coro
218}
219 212
220=item async_pool { ... } [@args...] 213=item async_pool { ... } [@args...]
221 214
222Similar to C<async>, but uses a coro pool, so you should not call 215Similar to C<async>, but uses a coro pool, so you should not call
223terminate or join on it (although you are allowed to), and you get a 216terminate or join on it (although you are allowed to), and you get a
… …
862works. 855works.
863 856
864=back 857=back
865 858
866 859
860=head1 WINDOWS PROCESS EMULATION
861
862A great many people seem to be confused about ithreads (for example, Chip
863Salzenberg called me unintelligent, incapable, stupid and gullible,
864while in the same mail making rather confused statements about perl
865ithreads (for example, that memory or files would be shared), showing his
866lack of understanding of this area - if it is hard to understand for Chip,
867it is probably not obvious to everybody).
868
869What follows is an ultra-condensed version of my talk about threads in
870scripting languages given onthe perl workshop 2009:
871
872The so-called "ithreads" were originally implemented for two reasons:
873first, to (badly) emulate unix processes on native win32 perls, and
874secondly, to replace the older, real thread model ("5.005-threads").
875
876It does that by using threads instead of OS processes. The difference
877between processes and threads is that threads share memory (and other
878state, such as files) between threads within a single process, while
879processes do not share anything (at least not semantically). That
880means that modifications done by one thread are seen by others, while
881modifications by one process are not seen by other processes.
882
883The "ithreads" work exactly like that: when creating a new ithreads
884process, all state is copied (memory is copied physically, files and code
885is copied logically). Afterwards, it isolates all modifications. On UNIX,
886the same behaviour can be achieved by using operating system processes,
887except that UNIX typically uses hardware built into the system to do this
888efficiently, while the windows process emulation emulates this hardware in
889software (rather efficiently, but of course it is still much slower than
890dedicated hardware).
891
892As mentioned before, loading code, modifying code, modifying data
893structures and so on is only visible in the ithreads process doing the
894modification, not in other ithread processes within the same OS process.
895
896This is why "ithreads" do not implement threads for perl at all, only
897processes. What makes it so bad is that on non-windows platforms, you can
898actually take advantage of custom hardware for this purpose (as evidenced
899by the forks module, which gives you the (i-) threads API, just much
900faster).
901
902Sharing data is in the i-threads model is done by transfering data
903structures between threads using copying semantics, which is very slow -
904shared data simply does not exist. Benchmarks using i-threads which are
905communication-intensive show extremely bad behaviour with i-threads (in
906fact, so bad that Coro, which cannot take direct advantage of multiple
907CPUs, is often orders of magnitude faster because it shares data using
908real threads, refer to my talk for details).
909
910As summary, i-threads *use* threads to implement processes, while
911the compatible forks module *uses* processes to emulate, uhm,
912processes. I-threads slow down every perl program when enabled, and
913outside of windows, serve no (or little) practical purpose, but
914disadvantages every single-threaded Perl program.
915
916This is the reason that I try to avoid the name "ithreads", as it is
917misleading as it implies that it implements some kind of thread model for
918perl, and prefer the name "windows process emulation", which describes the
919actual use and behaviour of it much better.
920
867=head1 SEE ALSO 921=head1 SEE ALSO
868 922
869Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>. 923Event-Loop integration: L<Coro::AnyEvent>, L<Coro::EV>, L<Coro::Event>.
870 924
871Debugging: L<Coro::Debug>. 925Debugging: L<Coro::Debug>.

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines