[ViewVC] Diff of: cvs/Coro/Coro.pm

Comparing Coro/Coro.pm (file contents):
Revision 1.256 by root, Wed Jun 17 21:38:23 2009 UTC vs.
Revision 1.269 by root, Thu Oct 1 23:25:03 2009 UTC

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

Diff Legend

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

Comparing Coro/Coro.pm (file contents): Revision 1.256 by root, Wed Jun 17 21:38:23 2009 UTC vs. Revision 1.269 by root, Thu Oct 1 23:25:03 2009 UTC

Diff Legend

Comparing Coro/Coro.pm (file contents):
Revision 1.256 by root, Wed Jun 17 21:38:23 2009 UTC vs.
Revision 1.269 by root, Thu Oct 1 23:25:03 2009 UTC