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

Comparing AnyEvent-Fork/Fork.pm (file contents):
Revision 1.23 by root, Sat Apr 6 08:29:43 2013 UTC vs.
Revision 1.63 by root, Wed Nov 26 13:36:18 2014 UTC

4 4
5=head1 SYNOPSIS 5=head1 SYNOPSIS
6 6
7 use AnyEvent::Fork; 7 use AnyEvent::Fork;
8 8
9 ################################################################## 9 AnyEvent::Fork
10 ->new
11 ->require ("MyModule")
12 ->run ("MyModule::server", my $cv = AE::cv);
13
14 my $fh = $cv->recv;
15
16=head1 DESCRIPTION
17
18This module allows you to create new processes, without actually forking
19them from your current process (avoiding the problems of forking), but
20preserving most of the advantages of fork.
21
22It can be used to create new worker processes or new independent
23subprocesses for short- and long-running jobs, process pools (e.g. for use
24in pre-forked servers) but also to spawn new external processes (such as
25CGI scripts from a web server), which can be faster (and more well behaved)
26than using fork+exec in big processes.
27
28Special care has been taken to make this module useful from other modules,
29while still supporting specialised environments such as L<App::Staticperl>
30or L<PAR::Packer>.
31
32=head2 WHAT THIS MODULE IS NOT
33
34This module only creates processes and lets you pass file handles and
35strings to it, and run perl code. It does not implement any kind of RPC -
36there is no back channel from the process back to you, and there is no RPC
37or message passing going on.
38
39If you need some form of RPC, you could use the L<AnyEvent::Fork::RPC>
40companion module, which adds simple RPC/job queueing to a process created
41by this module.
42
43And if you need some automatic process pool management on top of
44L<AnyEvent::Fork::RPC>, you can look at the L<AnyEvent::Fork::Pool>
45companion module.
46
47Or you can implement it yourself in whatever way you like: use some
48message-passing module such as L<AnyEvent::MP>, some pipe such as
49L<AnyEvent::ZeroMQ>, use L<AnyEvent::Handle> on both sides to send
50e.g. JSON or Storable messages, and so on.
51
52=head2 COMPARISON TO OTHER MODULES
53
54There is an abundance of modules on CPAN that do "something fork", such as
55L<Parallel::ForkManager>, L<AnyEvent::ForkManager>, L<AnyEvent::Worker>
56or L<AnyEvent::Subprocess>. There are modules that implement their own
57process management, such as L<AnyEvent::DBI>.
58
59The problems that all these modules try to solve are real, however, none
60of them (from what I have seen) tackle the very real problems of unwanted
61memory sharing, efficiency or not being able to use event processing, GUI
62toolkits or similar modules in the processes they create.
63
64This module doesn't try to replace any of them - instead it tries to solve
65the problem of creating processes with a minimum of fuss and overhead (and
66also luxury). Ideally, most of these would use AnyEvent::Fork internally,
67except they were written before AnyEvent:Fork was available, so obviously
68had to roll their own.
69
70=head2 PROBLEM STATEMENT
71
72There are two traditional ways to implement parallel processing on UNIX
73like operating systems - fork and process, and fork+exec and process. They
74have different advantages and disadvantages that I describe below,
75together with how this module tries to mitigate the disadvantages.
76
77=over 4
78
79=item Forking from a big process can be very slow.
80
81A 5GB process needs 0.05s to fork on my 3.6GHz amd64 GNU/Linux box. This
82overhead is often shared with exec (because you have to fork first), but
83in some circumstances (e.g. when vfork is used), fork+exec can be much
84faster.
85
86This module can help here by telling a small(er) helper process to fork,
87which is faster then forking the main process, and also uses vfork where
88possible. This gives the speed of vfork, with the flexibility of fork.
89
90=item Forking usually creates a copy-on-write copy of the parent
91process.
92
93For example, modules or data files that are loaded will not use additional
94memory after a fork. Exec'ing a new process, in contrast, means modules
95and data files might need to be loaded again, at extra CPU and memory
96cost.
97
98But when forking, you still create a copy of your data structures - if
99the program frees them and replaces them by new data, the child processes
100will retain the old version even if it isn't used, which can suddenly and
101unexpectedly increase memory usage when freeing memory.
102
103For example, L<Gtk2::CV> is an image viewer optimised for large
104directories (millions of pictures). It also forks subprocesses for
105thumbnail generation, which inherit the data structure that stores all
106file information. If the user changes the directory, it gets freed in
107the main process, leaving a copy in the thumbnailer processes. This can
108lead to many times the memory usage that would actually be required. The
109solution is to fork early (and being unable to dynamically generate more
110subprocesses or do this from a module)... or to use L<AnyEvent:Fork>.
111
112There is a trade-off between more sharing with fork (which can be good or
113bad), and no sharing with exec.
114
115This module allows the main program to do a controlled fork, and allows
116modules to exec processes safely at any time. When creating a custom
117process pool you can take advantage of data sharing via fork without
118risking to share large dynamic data structures that will blow up child
119memory usage.
120
121In other words, this module puts you into control over what is being
122shared and what isn't, at all times.
123
124=item Exec'ing a new perl process might be difficult.
125
126For example, it is not easy to find the correct path to the perl
127interpreter - C<$^X> might not be a perl interpreter at all. Worse, there
128might not even be a perl binary installed on the system.
129
130This module tries hard to identify the correct path to the perl
131interpreter. With a cooperative main program, exec'ing the interpreter
132might not even be necessary, but even without help from the main program,
133it will still work when used from a module.
134
135=item Exec'ing a new perl process might be slow, as all necessary modules
136have to be loaded from disk again, with no guarantees of success.
137
138Long running processes might run into problems when perl is upgraded
139and modules are no longer loadable because they refer to a different
140perl version, or parts of a distribution are newer than the ones already
141loaded.
142
143This module supports creating pre-initialised perl processes to be used as
144a template for new processes at a later time, e.g. for use in a process
145pool.
146
147=item Forking might be impossible when a program is running.
148
149For example, POSIX makes it almost impossible to fork from a
150multi-threaded program while doing anything useful in the child - in
151fact, if your perl program uses POSIX threads (even indirectly via
152e.g. L<IO::AIO> or L<threads>), you cannot call fork on the perl level
153anymore without risking memory corruption or worse on a number of
154operating systems.
155
156This module can safely fork helper processes at any time, by calling
157fork+exec in C, in a POSIX-compatible way (via L<Proc::FastSpawn>).
158
159=item Parallel processing with fork might be inconvenient or difficult
160to implement. Modules might not work in both parent and child.
161
162For example, when a program uses an event loop and creates watchers it
163becomes very hard to use the event loop from a child program, as the
164watchers already exist but are only meaningful in the parent. Worse, a
165module might want to use such a module, not knowing whether another module
166or the main program also does, leading to problems.
167
168Apart from event loops, graphical toolkits also commonly fall into the
169"unsafe module" category, or just about anything that communicates with
170the external world, such as network libraries and file I/O modules, which
171usually don't like being copied and then allowed to continue in two
172processes.
173
174With this module only the main program is allowed to create new processes
175by forking (because only the main program can know when it is still safe
176to do so) - all other processes are created via fork+exec, which makes it
177possible to use modules such as event loops or window interfaces safely.
178
179=back
180
181=head1 EXAMPLES
182
10 # create a single new process, tell it to run your worker function 183=head2 Create a single new process, tell it to run your worker function.
11 184
12 AnyEvent::Fork 185 AnyEvent::Fork
13 ->new 186 ->new
14 ->require ("MyModule") 187 ->require ("MyModule")
15 ->run ("MyModule::worker, sub { 188 ->run ("MyModule::worker, sub {
17 190
18 # now $master_filehandle is connected to the 191 # now $master_filehandle is connected to the
19 # $slave_filehandle in the new process. 192 # $slave_filehandle in the new process.
20 }); 193 });
21 194
22 # MyModule::worker might look like this 195C<MyModule> might look like this:
196
197 package MyModule;
198
23 sub MyModule::worker { 199 sub worker {
24 my ($slave_filehandle) = @_; 200 my ($slave_filehandle) = @_;
25 201
26 # now $slave_filehandle is connected to the $master_filehandle 202 # now $slave_filehandle is connected to the $master_filehandle
27 # in the original prorcess. have fun! 203 # in the original prorcess. have fun!
28 } 204 }
29 205
30 ##################################################################
31 # create a pool of server processes all accepting on the same socket 206=head2 Create a pool of server processes all accepting on the same socket.
32 207
33 # create listener socket 208 # create listener socket
34 my $listener = ...; 209 my $listener = ...;
35 210
36 # create a pool template, initialise it and give it the socket 211 # create a pool template, initialise it and give it the socket
48 } 223 }
49 224
50 # now do other things - maybe use the filehandle provided by run 225 # now do other things - maybe use the filehandle provided by run
51 # to wait for the processes to die. or whatever. 226 # to wait for the processes to die. or whatever.
52 227
53 # My::Server::run might look like this 228C<My::Server> might look like this:
54 sub My::Server::run { 229
230 package My::Server;
231
232 sub run {
55 my ($slave, $listener, $id) = @_; 233 my ($slave, $listener, $id) = @_;
56 234
57 close $slave; # we do not use the socket, so close it to save resources 235 close $slave; # we do not use the socket, so close it to save resources
58 236
59 # we could go ballistic and use e.g. AnyEvent here, or IO::AIO, 237 # we could go ballistic and use e.g. AnyEvent here, or IO::AIO,
61 while (my $socket = $listener->accept) { 239 while (my $socket = $listener->accept) {
62 # do sth. with new socket 240 # do sth. with new socket
63 } 241 }
64 } 242 }
65 243
66 ##################################################################
67 # use AnyEvent::Fork as a faster fork+exec 244=head2 use AnyEvent::Fork as a faster fork+exec
68 245
69 # this runs /bin/echo hi, with stdout redirected to /tmp/log 246This runs C</bin/echo hi>, with standard output redirected to F</tmp/log>
70 # and stderr to the communications socket. it is usually faster 247and standard error redirected to the communications socket. It is usually
71 # than fork+exec, but still let's you prepare the environment. 248faster than fork+exec, but still lets you prepare the environment.
72 249
73 open my $output, ">/tmp/log" or die "$!"; 250 open my $output, ">/tmp/log" or die "$!";
74 251
75 AnyEvent::Fork 252 AnyEvent::Fork
76 ->new 253 ->new
77 ->eval (' 254 ->eval ('
255 # compile a helper function for later use
78 sub run { 256 sub run {
79 my ($fh, $output, @cmd) = @_; 257 my ($fh, $output, @cmd) = @_;
80 258
81 # perl will clear close-on-exec on STDOUT/STDERR 259 # perl will clear close-on-exec on STDOUT/STDERR
82 open STDOUT, ">&", $output or die; 260 open STDOUT, ">&", $output or die;
89 ->send_arg ("/bin/echo", "hi") 267 ->send_arg ("/bin/echo", "hi")
90 ->run ("run", my $cv = AE::cv); 268 ->run ("run", my $cv = AE::cv);
91 269
92 my $stderr = $cv->recv; 270 my $stderr = $cv->recv;
93 271
94=head1 DESCRIPTION 272=head2 For stingy users: put the worker code into a C<DATA> section.
95 273
96This module allows you to create new processes, without actually forking 274When you want to be stingy with files, you can put your code into the
97them from your current process (avoiding the problems of forking), but 275C<DATA> section of your module (or program):
98preserving most of the advantages of fork.
99 276
100It can be used to create new worker processes or new independent 277 use AnyEvent::Fork;
101subprocesses for short- and long-running jobs, process pools (e.g. for use
102in pre-forked servers) but also to spawn new external processes (such as
103CGI scripts from a web server), which can be faster (and more well behaved)
104than using fork+exec in big processes.
105 278
106Special care has been taken to make this module useful from other modules, 279 AnyEvent::Fork
107while still supporting specialised environments such as L<App::Staticperl> 280 ->new
108or L<PAR::Packer>. 281 ->eval (do { local $/; <DATA> })
282 ->run ("doit", sub { ... });
109 283
110=head1 WHAT THIS MODULE IS NOT 284 __DATA__
111 285
112This module only creates processes and lets you pass file handles and 286 sub doit {
113strings to it, and run perl code. It does not implement any kind of RPC - 287 ... do something!
114there is no back channel from the process back to you, and there is no RPC 288 }
115or message passing going on.
116 289
117If you need some form of RPC, you can either implement it yourself 290=head2 For stingy standalone programs: do not rely on external files at
118in whatever way you like, use some message-passing module such 291all.
119as L<AnyEvent::MP>, some pipe such as L<AnyEvent::ZeroMQ>, use
120L<AnyEvent::Handle> on both sides to send e.g. JSON or Storable messages,
121and so on.
122 292
123=head1 PROBLEM STATEMENT 293For single-file scripts it can be inconvenient to rely on external
294files - even when using a C<DATA> section, you still need to C<exec> an
295external perl interpreter, which might not be available when using
296L<App::Staticperl>, L<Urlader> or L<PAR::Packer> for example.
124 297
125There are two ways to implement parallel processing on UNIX like operating 298Two modules help here - L<AnyEvent::Fork::Early> forks a template process
126systems - fork and process, and fork+exec and process. They have different 299for all further calls to C<new_exec>, and L<AnyEvent::Fork::Template>
127advantages and disadvantages that I describe below, together with how this 300forks the main program as a template process.
128module tries to mitigate the disadvantages.
129 301
130=over 4 302Here is how your main program should look like:
131 303
132=item Forking from a big process can be very slow (a 5GB process needs 304 #! perl
1330.05s to fork on my 3.6GHz amd64 GNU/Linux box for example). This overhead
134is often shared with exec (because you have to fork first), but in some
135circumstances (e.g. when vfork is used), fork+exec can be much faster.
136 305
137This module can help here by telling a small(er) helper process to fork, 306 # optional, as the very first thing.
138or fork+exec instead. 307 # in case modules want to create their own processes.
308 use AnyEvent::Fork::Early;
139 309
140=item Forking usually creates a copy-on-write copy of the parent 310 # next, load all modules you need in your template process
141process. Memory (for example, modules or data files that have been 311 use Example::My::Module
142will not take additional memory). When exec'ing a new process, modules 312 use Example::Whatever;
143and data files might need to be loaded again, at extra CPU and memory
144cost. Likewise when forking, all data structures are copied as well - if
145the program frees them and replaces them by new data, the child processes
146will retain the memory even if it isn't used.
147 313
148This module allows the main program to do a controlled fork, and allows 314 # next, put your run function definition and anything else you
149modules to exec processes safely at any time. When creating a custom 315 # need, but do not use code outside of BEGIN blocks.
150process pool you can take advantage of data sharing via fork without 316 sub worker_run {
151risking to share large dynamic data structures that will blow up child 317 my ($fh, @args) = @_;
152memory usage. 318 ...
319 }
153 320
154=item Exec'ing a new perl process might be difficult and slow. For 321 # now preserve everything so far as AnyEvent::Fork object
155example, it is not easy to find the correct path to the perl interpreter, 322 # in $TEMPLATE.
156and all modules have to be loaded from disk again. Long running processes 323 use AnyEvent::Fork::Template;
157might run into problems when perl is upgraded for example.
158 324
159This module supports creating pre-initialised perl processes to be used 325 # do not put code outside of BEGIN blocks until here
160as template, and also tries hard to identify the correct path to the perl
161interpreter. With a cooperative main program, exec'ing the interpreter
162might not even be necessary.
163 326
164=item Forking might be impossible when a program is running. For example, 327 # now use the $TEMPLATE process in any way you like
165POSIX makes it almost impossible to fork from a multi-threaded program and
166do anything useful in the child - strictly speaking, if your perl program
167uses posix threads (even indirectly via e.g. L<IO::AIO> or L<threads>),
168you cannot call fork on the perl level anymore, at all.
169 328
170This module can safely fork helper processes at any time, by calling 329 # for example: create 10 worker processes
171fork+exec in C, in a POSIX-compatible way. 330 my @worker;
172 331 my $cv = AE::cv;
173=item Parallel processing with fork might be inconvenient or difficult 332 for (1..10) {
174to implement. For example, when a program uses an event loop and creates 333 $cv->begin;
175watchers it becomes very hard to use the event loop from a child 334 $TEMPLATE->fork->send_arg ($_)->run ("worker_run", sub {
176program, as the watchers already exist but are only meaningful in the 335 push @worker, shift;
177parent. Worse, a module might want to use such a system, not knowing 336 $cv->end;
178whether another module or the main program also does, leading to problems. 337 });
179 338 }
180This module only lets the main program create pools by forking (because 339 $cv->recv;
181only the main program can know when it is still safe to do so) - all other
182pools are created by fork+exec, after which such modules can again be
183loaded.
184
185=back
186 340
187=head1 CONCEPTS 341=head1 CONCEPTS
188 342
189This module can create new processes either by executing a new perl 343This module can create new processes either by executing a new perl
190process, or by forking from an existing "template" process. 344process, or by forking from an existing "template" process.
345
346All these processes are called "child processes" (whether they are direct
347children or not), while the process that manages them is called the
348"parent process".
191 349
192Each such process comes with its own file handle that can be used to 350Each such process comes with its own file handle that can be used to
193communicate with it (it's actually a socket - one end in the new process, 351communicate with it (it's actually a socket - one end in the new process,
194one end in the main process), and among the things you can do in it are 352one end in the main process), and among the things you can do in it are
195load modules, fork new processes, send file handles to it, and execute 353load modules, fork new processes, send file handles to it, and execute
269 my ($fork_fh) = @_; 427 my ($fork_fh) = @_;
270 }); 428 });
271 429
272=back 430=back
273 431
274=head1 FUNCTIONS 432=head1 THE C<AnyEvent::Fork> CLASS
433
434This module exports nothing, and only implements a single class -
435C<AnyEvent::Fork>.
436
437There are two class constructors that both create new processes - C<new>
438and C<new_exec>. The C<fork> method creates a new process by forking an
439existing one and could be considered a third constructor.
440
441Most of the remaining methods deal with preparing the new process, by
442loading code, evaluating code and sending data to the new process. They
443usually return the process object, so you can chain method calls.
444
445If a process object is destroyed before calling its C<run> method, then
446the process simply exits. After C<run> is called, all responsibility is
447passed to the specified function.
448
449As long as there is any outstanding work to be done, process objects
450resist being destroyed, so there is no reason to store them unless you
451need them later - configure and forget works just fine.
275 452
276=over 4 453=over 4
277 454
278=cut 455=cut
279 456
286use AnyEvent; 463use AnyEvent;
287use AnyEvent::Util (); 464use AnyEvent::Util ();
288 465
289use IO::FDPass; 466use IO::FDPass;
290 467
291our $VERSION = 0.5; 468our $VERSION = 1.2;
292
293our $PERL; # the path to the perl interpreter, deduces with various forms of magic
294
295=item my $pool = new AnyEvent::Fork key => value...
296
297Create a new process pool. The following named parameters are supported:
298
299=over 4
300
301=back
302
303=cut
304 469
305# the early fork template process 470# the early fork template process
306our $EARLY; 471our $EARLY;
307 472
308# the empty template process 473# the empty template process
309our $TEMPLATE; 474our $TEMPLATE;
475
476sub QUEUE() { 0 }
477sub FH() { 1 }
478sub WW() { 2 }
479sub PID() { 3 }
480sub CB() { 4 }
481
482sub _new {
483 my ($self, $fh, $pid) = @_;
484
485 AnyEvent::Util::fh_nonblocking $fh, 1;
486
487 $self = bless [
488 [], # write queue - strings or fd's
489 $fh,
490 undef, # AE watcher
491 $pid,
492 ], $self;
493
494 $self
495}
310 496
311sub _cmd { 497sub _cmd {
312 my $self = shift; 498 my $self = shift;
313 499
314 # ideally, we would want to use "a (w/a)*" as format string, but perl 500 # ideally, we would want to use "a (w/a)*" as format string, but perl
315 # versions from at least 5.8.9 to 5.16.3 are all buggy and can't unpack 501 # versions from at least 5.8.9 to 5.16.3 are all buggy and can't unpack
316 # it. 502 # it.
317 push @{ $self->[2] }, pack "a L/a*", $_[0], $_[1]; 503 push @{ $self->[QUEUE] }, pack "a L/a*", $_[0], $_[1];
318 504
319 $self->[3] ||= AE::io $self->[1], 1, sub { 505 $self->[WW] ||= AE::io $self->[FH], 1, sub {
320 do { 506 do {
321 # send the next "thing" in the queue - either a reference to an fh, 507 # send the next "thing" in the queue - either a reference to an fh,
322 # or a plain string. 508 # or a plain string.
323 509
324 if (ref $self->[2][0]) { 510 if (ref $self->[QUEUE][0]) {
325 # send fh 511 # send fh
326 unless (IO::FDPass::send fileno $self->[1], fileno ${ $self->[2][0] }) { 512 unless (IO::FDPass::send fileno $self->[FH], fileno ${ $self->[QUEUE][0] }) {
327 return if $! == Errno::EAGAIN || $! == Errno::EWOULDBLOCK; 513 return if $! == Errno::EAGAIN || $! == Errno::EWOULDBLOCK;
328 undef $self->[3]; 514 undef $self->[WW];
329 die "AnyEvent::Fork: file descriptor send failure: $!"; 515 die "AnyEvent::Fork: file descriptor send failure: $!";
330 } 516 }
331 517
332 shift @{ $self->[2] }; 518 shift @{ $self->[QUEUE] };
333 519
334 } else { 520 } else {
335 # send string 521 # send string
336 my $len = syswrite $self->[1], $self->[2][0]; 522 my $len = syswrite $self->[FH], $self->[QUEUE][0];
337 523
338 unless ($len) { 524 unless ($len) {
339 return if $! == Errno::EAGAIN || $! == Errno::EWOULDBLOCK; 525 return if $! == Errno::EAGAIN || $! == Errno::EWOULDBLOCK;
340 undef $self->[3]; 526 undef $self->[WW];
341 die "AnyEvent::Fork: command write failure: $!"; 527 die "AnyEvent::Fork: command write failure: $!";
342 } 528 }
343 529
344 substr $self->[2][0], 0, $len, ""; 530 substr $self->[QUEUE][0], 0, $len, "";
345 shift @{ $self->[2] } unless length $self->[2][0]; 531 shift @{ $self->[QUEUE] } unless length $self->[QUEUE][0];
346 } 532 }
347 } while @{ $self->[2] }; 533 } while @{ $self->[QUEUE] };
348 534
349 # everything written 535 # everything written
350 undef $self->[3]; 536 undef $self->[WW];
351 537
352 # invoke run callback, if any 538 # invoke run callback, if any
353 $self->[4]->($self->[1]) if $self->[4]; 539 if ($self->[CB]) {
540 $self->[CB]->($self->[FH]);
541 @$self = ();
542 }
354 }; 543 };
355 544
356 () # make sure we don't leak the watcher 545 () # make sure we don't leak the watcher
357}
358
359sub _new {
360 my ($self, $fh, $pid) = @_;
361
362 AnyEvent::Util::fh_nonblocking $fh, 1;
363
364 $self = bless [
365 $pid,
366 $fh,
367 [], # write queue - strings or fd's
368 undef, # AE watcher
369 ], $self;
370
371 $self
372} 546}
373 547
374# fork template from current process, used by AnyEvent::Fork::Early/Template 548# fork template from current process, used by AnyEvent::Fork::Early/Template
375sub _new_fork { 549sub _new_fork {
376 my ($fh, $slave) = AnyEvent::Util::portable_socketpair; 550 my ($fh, $slave) = AnyEvent::Util::portable_socketpair;
381 if ($pid eq 0) { 555 if ($pid eq 0) {
382 require AnyEvent::Fork::Serve; 556 require AnyEvent::Fork::Serve;
383 $AnyEvent::Fork::Serve::OWNER = $parent; 557 $AnyEvent::Fork::Serve::OWNER = $parent;
384 close $fh; 558 close $fh;
385 $0 = "$_[1] of $parent"; 559 $0 = "$_[1] of $parent";
386 $SIG{CHLD} = 'IGNORE';
387 AnyEvent::Fork::Serve::serve ($slave); 560 AnyEvent::Fork::Serve::serve ($slave);
388 exit 0; 561 exit 0;
389 } elsif (!$pid) { 562 } elsif (!$pid) {
390 die "AnyEvent::Fork::Early/Template: unable to fork template process: $!"; 563 die "AnyEvent::Fork::Early/Template: unable to fork template process: $!";
391 } 564 }
398Create a new "empty" perl interpreter process and returns its process 571Create a new "empty" perl interpreter process and returns its process
399object for further manipulation. 572object for further manipulation.
400 573
401The new process is forked from a template process that is kept around 574The new process is forked from a template process that is kept around
402for this purpose. When it doesn't exist yet, it is created by a call to 575for this purpose. When it doesn't exist yet, it is created by a call to
403C<new_exec> and kept around for future calls. 576C<new_exec> first and then stays around for future calls.
404
405When the process object is destroyed, it will release the file handle
406that connects it with the new process. When the new process has not yet
407called C<run>, then the process will exit. Otherwise, what happens depends
408entirely on the code that is executed.
409 577
410=cut 578=cut
411 579
412sub new { 580sub new {
413 my $class = shift; 581 my $class = shift;
450 618
451You should use C<new> whenever possible, except when having a template 619You should use C<new> whenever possible, except when having a template
452process around is unacceptable. 620process around is unacceptable.
453 621
454The path to the perl interpreter is divined using various methods - first 622The path to the perl interpreter is divined using various methods - first
455C<$^X> is investigated to see if the path ends with something that sounds 623C<$^X> is investigated to see if the path ends with something that looks
456as if it were the perl interpreter. Failing this, the module falls back to 624as if it were the perl interpreter. Failing this, the module falls back to
457using C<$Config::Config{perlpath}>. 625using C<$Config::Config{perlpath}>.
458 626
627The path to perl can also be overriden by setting the global variable
628C<$AnyEvent::Fork::PERL> - it's value will be used for all subsequent
629invocations.
630
459=cut 631=cut
632
633our $PERL;
460 634
461sub new_exec { 635sub new_exec {
462 my ($self) = @_; 636 my ($self) = @_;
463 637
464 return $EARLY->fork 638 return $EARLY->fork
465 if $EARLY; 639 if $EARLY;
466 640
641 unless (defined $PERL) {
467 # first find path of perl 642 # first find path of perl
468 my $perl = $; 643 my $perl = $^X;
469 644
470 # first we try $^X, but the path must be absolute (always on win32), and end in sth. 645 # first we try $^X, but the path must be absolute (always on win32), and end in sth.
471 # that looks like perl. this obviously only works for posix and win32 646 # that looks like perl. this obviously only works for posix and win32
472 unless ( 647 unless (
473 ($^O eq "MSWin32" || $perl =~ m%^/%) 648 ($^O eq "MSWin32" || $perl =~ m%^/%)
474 && $perl =~ m%[/\\]perl(?:[0-9]+(\.[0-9]+)+)?(\.exe)?$%i 649 && $perl =~ m%[/\\]perl(?:[0-9]+(\.[0-9]+)+)?(\.exe)?$%i
475 ) { 650 ) {
476 # if it doesn't look perlish enough, try Config 651 # if it doesn't look perlish enough, try Config
477 require Config; 652 require Config;
478 $perl = $Config::Config{perlpath}; 653 $perl = $Config::Config{perlpath};
479 $perl =~ s/(?:\Q$Config::Config{_exe}\E)?$/$Config::Config{_exe}/; 654 $perl =~ s/(?:\Q$Config::Config{_exe}\E)?$/$Config::Config{_exe}/;
655 }
656
657 $PERL = $perl;
480 } 658 }
481 659
482 require Proc::FastSpawn; 660 require Proc::FastSpawn;
483 661
484 my ($fh, $slave) = AnyEvent::Util::portable_socketpair; 662 my ($fh, $slave) = AnyEvent::Util::portable_socketpair;
492 #local $ENV{PERL5LIB} = join ":", grep !ref, @INC; 670 #local $ENV{PERL5LIB} = join ":", grep !ref, @INC;
493 my %env = %ENV; 671 my %env = %ENV;
494 $env{PERL5LIB} = join +($^O eq "MSWin32" ? ";" : ":"), grep !ref, @INC; 672 $env{PERL5LIB} = join +($^O eq "MSWin32" ? ";" : ":"), grep !ref, @INC;
495 673
496 my $pid = Proc::FastSpawn::spawn ( 674 my $pid = Proc::FastSpawn::spawn (
497 $perl, 675 $PERL,
498 ["perl", "-MAnyEvent::Fork::Serve", "-e", "AnyEvent::Fork::Serve::me", fileno $slave, $$], 676 ["perl", "-MAnyEvent::Fork::Serve", "-e", "AnyEvent::Fork::Serve::me", fileno $slave, $$],
499 [map "$_=$env{$_}", keys %env], 677 [map "$_=$env{$_}", keys %env],
500 ) or die "unable to spawn AnyEvent::Fork server: $!"; 678 ) or die "unable to spawn AnyEvent::Fork server: $!";
501 679
502 $self->_new ($fh, $pid) 680 $self->_new ($fh, $pid)
503} 681}
504 682
505=item $pid = $proc->pid 683=item $pid = $proc->pid
506 684
507Returns the process id of the process I<iff it is a direct child of the 685Returns the process id of the process I<iff it is a direct child of the
508process> running AnyEvent::Fork, and C<undef> otherwise. 686process running AnyEvent::Fork>, and C<undef> otherwise. As a general
687rule (that you cannot rely upon), processes created via C<new_exec>,
688L<AnyEvent::Fork::Early> or L<AnyEvent::Fork::Template> are direct
689children, while all other processes are not.
509 690
510Normally, only processes created via C<< AnyEvent::Fork->new_exec >> and 691Or in other words, you do not normally have to take care of zombies for
511L<AnyEvent::Fork::Template> are direct children, and you are responsible 692processes created via C<new>, but when in doubt, or zombies are a problem,
512to clean up their zombies when they die. 693you need to check whether a process is a diretc child by calling this
513 694method, and possibly creating a child watcher or reap it manually.
514All other processes are not direct children, and will be cleaned up by
515AnyEvent::Fork.
516 695
517=cut 696=cut
518 697
519sub pid { 698sub pid {
520 $_[0][0] 699 $_[0][PID]
521} 700}
522 701
523=item $proc = $proc->eval ($perlcode, @args) 702=item $proc = $proc->eval ($perlcode, @args)
524 703
525Evaluates the given C<$perlcode> as ... perl code, while setting C<@_> to 704Evaluates the given C<$perlcode> as ... Perl code, while setting C<@_> to
526the strings specified by C<@args>, in the "main" package. 705the strings specified by C<@args>, in the "main" package.
527 706
528This call is meant to do any custom initialisation that might be required 707This call is meant to do any custom initialisation that might be required
529(for example, the C<require> method uses it). It's not supposed to be used 708(for example, the C<require> method uses it). It's not supposed to be used
530to completely take over the process, use C<run> for that. 709to completely take over the process, use C<run> for that.
531 710
532The code will usually be executed after this call returns, and there is no 711The code will usually be executed after this call returns, and there is no
533way to pass anything back to the calling process. Any evaluation errors 712way to pass anything back to the calling process. Any evaluation errors
534will be reported to stderr and cause the process to exit. 713will be reported to stderr and cause the process to exit.
535 714
536If you want to execute some code to take over the process (see the 715If you want to execute some code (that isn't in a module) to take over the
537"fork+exec" example in the SYNOPSIS), you should compile a function via 716process, you should compile a function via C<eval> first, and then call
538C<eval> first, and then call it via C<run>. This also gives you access to 717it via C<run>. This also gives you access to any arguments passed via the
539any arguments passed via the C<send_xxx> methods, such as file handles. 718C<send_xxx> methods, such as file handles. See the L<use AnyEvent::Fork as
719a faster fork+exec> example to see it in action.
540 720
541Returns the process object for easy chaining of method calls. 721Returns the process object for easy chaining of method calls.
542 722
543=cut 723=cut
544 724
570=item $proc = $proc->send_fh ($handle, ...) 750=item $proc = $proc->send_fh ($handle, ...)
571 751
572Send one or more file handles (I<not> file descriptors) to the process, 752Send one or more file handles (I<not> file descriptors) to the process,
573to prepare a call to C<run>. 753to prepare a call to C<run>.
574 754
575The process object keeps a reference to the handles until this is done, 755The process object keeps a reference to the handles until they have
576so you must not explicitly close the handles. This is most easily 756been passed over to the process, so you must not explicitly close the
577accomplished by simply not storing the file handles anywhere after passing 757handles. This is most easily accomplished by simply not storing the file
578them to this method. 758handles anywhere after passing them to this method - when AnyEvent::Fork
759is finished using them, perl will automatically close them.
579 760
580Returns the process object for easy chaining of method calls. 761Returns the process object for easy chaining of method calls.
581 762
582Example: pass a file handle to a process, and release it without 763Example: pass a file handle to a process, and release it without
583closing. It will be closed automatically when it is no longer used. 764closing. It will be closed automatically when it is no longer used.
590sub send_fh { 771sub send_fh {
591 my ($self, @fh) = @_; 772 my ($self, @fh) = @_;
592 773
593 for my $fh (@fh) { 774 for my $fh (@fh) {
594 $self->_cmd ("h"); 775 $self->_cmd ("h");
595 push @{ $self->[2] }, \$fh; 776 push @{ $self->[QUEUE] }, \$fh;
596 } 777 }
597 778
598 $self 779 $self
599} 780}
600 781
601=item $proc = $proc->send_arg ($string, ...) 782=item $proc = $proc->send_arg ($string, ...)
602 783
603Send one or more argument strings to the process, to prepare a call to 784Send one or more argument strings to the process, to prepare a call to
604C<run>. The strings can be any octet string. 785C<run>. The strings can be any octet strings.
605 786
606The protocol is optimised to pass a moderate number of relatively short 787The protocol is optimised to pass a moderate number of relatively short
607strings - while you can pass up to 4GB of data in one go, this is more 788strings - while you can pass up to 4GB of data in one go, this is more
608meant to pass some ID information or other startup info, not big chunks of 789meant to pass some ID information or other startup info, not big chunks of
609data. 790data.
625Enter the function specified by the function name in C<$func> in the 806Enter the function specified by the function name in C<$func> in the
626process. The function is called with the communication socket as first 807process. The function is called with the communication socket as first
627argument, followed by all file handles and string arguments sent earlier 808argument, followed by all file handles and string arguments sent earlier
628via C<send_fh> and C<send_arg> methods, in the order they were called. 809via C<send_fh> and C<send_arg> methods, in the order they were called.
629 810
811The process object becomes unusable on return from this function - any
812further method calls result in undefined behaviour.
813
630The function name should be fully qualified, but if it isn't, it will be 814The function name should be fully qualified, but if it isn't, it will be
631looked up in the main package. 815looked up in the C<main> package.
632 816
633If the called function returns, doesn't exist, or any error occurs, the 817If the called function returns, doesn't exist, or any error occurs, the
634process exits. 818process exits.
635 819
636Preparing the process is done in the background - when all commands have 820Preparing the process is done in the background - when all commands have
637been sent, the callback is invoked with the local communications socket 821been sent, the callback is invoked with the local communications socket
638as argument. At this point you can start using the socket in any way you 822as argument. At this point you can start using the socket in any way you
639like. 823like.
640 824
641The process object becomes unusable on return from this function - any
642further method calls result in undefined behaviour.
643
644If the communication socket isn't used, it should be closed on both sides, 825If the communication socket isn't used, it should be closed on both sides,
645to save on kernel memory. 826to save on kernel memory.
646 827
647The socket is non-blocking in the parent, and blocking in the newly 828The socket is non-blocking in the parent, and blocking in the newly
648created process. The close-on-exec flag is set in both. 829created process. The close-on-exec flag is set in both.
649 830
650Even if not used otherwise, the socket can be a good indicator for the 831Even if not used otherwise, the socket can be a good indicator for the
651existence of the process - if the other process exits, you get a readable 832existence of the process - if the other process exits, you get a readable
652event on it, because exiting the process closes the socket (if it didn't 833event on it, because exiting the process closes the socket (if it didn't
653create any children using fork). 834create any children using fork).
835
836=over 4
837
838=item Compatibility to L<AnyEvent::Fork::Remote>
839
840If you want to write code that works with both this module and
841L<AnyEvent::Fork::Remote>, you need to write your code so that it assumes
842there are two file handles for communications, which might not be unix
843domain sockets. The C<run> function should start like this:
844
845 sub run {
846 my ($rfh, @args) = @_; # @args is your normal arguments
847 my $wfh = fileno $rfh ? $rfh : *STDOUT;
848
849 # now use $rfh for reading and $wfh for writing
850 }
851
852This checks whether the passed file handle is, in fact, the process
853C<STDIN> handle. If it is, then the function was invoked visa
854L<AnyEvent::Fork::Remote>, so STDIN should be used for reading and
855C<STDOUT> should be used for writing.
856
857In all other cases, the function was called via this module, and there is
858only one file handle that should be sued for reading and writing.
859
860=back
654 861
655Example: create a template for a process pool, pass a few strings, some 862Example: create a template for a process pool, pass a few strings, some
656file handles, then fork, pass one more string, and run some code. 863file handles, then fork, pass one more string, and run some code.
657 864
658 my $pool = AnyEvent::Fork 865 my $pool = AnyEvent::Fork
686=cut 893=cut
687 894
688sub run { 895sub run {
689 my ($self, $func, $cb) = @_; 896 my ($self, $func, $cb) = @_;
690 897
691 $self->[4] = $cb; 898 $self->[CB] = $cb;
692 $self->_cmd (r => $func); 899 $self->_cmd (r => $func);
900}
901
902=back
903
904=head2 EXPERIMENTAL METHODS
905
906These methods might go away completely or change behaviour, at any time.
907
908=over 4
909
910=item $proc->to_fh ($cb->($fh)) # EXPERIMENTAL, MIGHT BE REMOVED
911
912Flushes all commands out to the process and then calls the callback with
913the communications socket.
914
915The process object becomes unusable on return from this function - any
916further method calls result in undefined behaviour.
917
918The point of this method is to give you a file handle that you can pass
919to another process. In that other process, you can call C<new_from_fh
920AnyEvent::Fork $fh> to create a new C<AnyEvent::Fork> object from it,
921thereby effectively passing a fork object to another process.
922
923=cut
924
925sub to_fh {
926 my ($self, $cb) = @_;
927
928 $self->[CB] = $cb;
929
930 unless ($self->[WW]) {
931 $self->[CB]->($self->[FH]);
932 @$self = ();
933 }
934}
935
936=item new_from_fh AnyEvent::Fork $fh # EXPERIMENTAL, MIGHT BE REMOVED
937
938Takes a file handle originally rceeived by the C<to_fh> method and creates
939a new C<AnyEvent:Fork> object. The child process itself will not change in
940any way, i.e. it will keep all the modifications done to it before calling
941C<to_fh>.
942
943The new object is very much like the original object, except that the
944C<pid> method will return C<undef> even if the process is a direct child.
945
946=cut
947
948sub new_from_fh {
949 my ($class, $fh) = @_;
950
951 $class->_new ($fh)
693} 952}
694 953
695=back 954=back
696 955
697=head1 PERFORMANCE 956=head1 PERFORMANCE
707 966
708 2079 new processes per second, using manual socketpair + fork 967 2079 new processes per second, using manual socketpair + fork
709 968
710Then I did the same thing, but instead of calling fork, I called 969Then I did the same thing, but instead of calling fork, I called
711AnyEvent::Fork->new->run ("CORE::exit") and then again waited for the 970AnyEvent::Fork->new->run ("CORE::exit") and then again waited for the
712socket form the child to close on exit. This does the same thing as manual 971socket from the child to close on exit. This does the same thing as manual
713socket pair + fork, except that what is forked is the template process 972socket pair + fork, except that what is forked is the template process
714(2440kB), and the socket needs to be passed to the server at the other end 973(2440kB), and the socket needs to be passed to the server at the other end
715of the socket first. 974of the socket first.
716 975
717 2307 new processes per second, using AnyEvent::Fork->new 976 2307 new processes per second, using AnyEvent::Fork->new
722 479 vfork+execs per second, using AnyEvent::Fork->new_exec 981 479 vfork+execs per second, using AnyEvent::Fork->new_exec
723 982
724So how can C<< AnyEvent->new >> be faster than a standard fork, even 983So how can C<< AnyEvent->new >> be faster than a standard fork, even
725though it uses the same operations, but adds a lot of overhead? 984though it uses the same operations, but adds a lot of overhead?
726 985
727The difference is simply the process size: forking the 6MB process takes 986The difference is simply the process size: forking the 5MB process takes
728so much longer than forking the 2.5MB template process that the overhead 987so much longer than forking the 2.5MB template process that the extra
729introduced is canceled out. 988overhead is canceled out.
730 989
731If the benchmark process grows, the normal fork becomes even slower: 990If the benchmark process grows, the normal fork becomes even slower:
732 991
733 1340 new processes, manual fork in a 20MB process 992 1340 new processes, manual fork of a 20MB process
734 731 new processes, manual fork in a 200MB process 993 731 new processes, manual fork of a 200MB process
735 235 new processes, manual fork in a 2000MB process 994 235 new processes, manual fork of a 2000MB process
736 995
737What that means (to me) is that I can use this module without having a 996What that means (to me) is that I can use this module without having a bad
738very bad conscience because of the extra overhead required to start new 997conscience because of the extra overhead required to start new processes.
739processes.
740 998
741=head1 TYPICAL PROBLEMS 999=head1 TYPICAL PROBLEMS
742 1000
743This section lists typical problems that remain. I hope by recognising 1001This section lists typical problems that remain. I hope by recognising
744them, most can be avoided. 1002them, most can be avoided.
745 1003
746=over 4 1004=over 4
747 1005
748=item "leaked" file descriptors for exec'ed processes 1006=item leaked file descriptors for exec'ed processes
749 1007
750POSIX systems inherit file descriptors by default when exec'ing a new 1008POSIX systems inherit file descriptors by default when exec'ing a new
751process. While perl itself laudably sets the close-on-exec flags on new 1009process. While perl itself laudably sets the close-on-exec flags on new
752file handles, most C libraries don't care, and even if all cared, it's 1010file handles, most C libraries don't care, and even if all cared, it's
753often not possible to set the flag in a race-free manner. 1011often not possible to set the flag in a race-free manner.
773libraries or the code that leaks those file descriptors. 1031libraries or the code that leaks those file descriptors.
774 1032
775Fortunately, most of these leaked descriptors do no harm, other than 1033Fortunately, most of these leaked descriptors do no harm, other than
776sitting on some resources. 1034sitting on some resources.
777 1035
778=item "leaked" file descriptors for fork'ed processes 1036=item leaked file descriptors for fork'ed processes
779 1037
780Normally, L<AnyEvent::Fork> does start new processes by exec'ing them, 1038Normally, L<AnyEvent::Fork> does start new processes by exec'ing them,
781which closes file descriptors not marked for being inherited. 1039which closes file descriptors not marked for being inherited.
782 1040
783However, L<AnyEvent::Fork::Early> and L<AnyEvent::Fork::Template> offer 1041However, L<AnyEvent::Fork::Early> and L<AnyEvent::Fork::Template> offer
792 1050
793The solution is to either not load these modules before use'ing 1051The solution is to either not load these modules before use'ing
794L<AnyEvent::Fork::Early> or L<AnyEvent::Fork::Template>, or to delay 1052L<AnyEvent::Fork::Early> or L<AnyEvent::Fork::Template>, or to delay
795initialising them, for example, by calling C<init Gtk2> manually. 1053initialising them, for example, by calling C<init Gtk2> manually.
796 1054
797=item exit runs destructors 1055=item exiting calls object destructors
798 1056
799This only applies to users of Lc<AnyEvent::Fork:Early> and 1057This only applies to users of L<AnyEvent::Fork:Early> and
800L<AnyEvent::Fork::Template>. 1058L<AnyEvent::Fork::Template>, or when initialising code creates objects
1059that reference external resources.
801 1060
802When a process created by AnyEvent::Fork exits, it might do so by calling 1061When a process created by AnyEvent::Fork exits, it might do so by calling
803exit, or simply letting perl reach the end of the program. At which point 1062exit, or simply letting perl reach the end of the program. At which point
804Perl runs all destructors. 1063Perl runs all destructors.
805 1064
824to make it so, mostly due to the bloody broken perl that nobody seems to 1083to make it so, mostly due to the bloody broken perl that nobody seems to
825care about. The fork emulation is a bad joke - I have yet to see something 1084care about. The fork emulation is a bad joke - I have yet to see something
826useful that you can do with it without running into memory corruption 1085useful that you can do with it without running into memory corruption
827issues or other braindamage. Hrrrr. 1086issues or other braindamage. Hrrrr.
828 1087
829Cygwin perl is not supported at the moment, as it should implement fd 1088Since fork is endlessly broken on win32 perls (it doesn't even remotely
830passing, but doesn't, and rolling my own is hard, as cygwin doesn't 1089work within it's documented limits) and quite obviously it's not getting
831support enough functionality to do it. 1090improved any time soon, the best way to proceed on windows would be to
1091always use C<new_exec> and thus never rely on perl's fork "emulation".
1092
1093Cygwin perl is not supported at the moment due to some hilarious
1094shortcomings of its API - see L<IO::FDPoll> for more details. If you never
1095use C<send_fh> and always use C<new_exec> to create processes, it should
1096work though.
1097
1098=head1 USING AnyEvent::Fork IN SUBPROCESSES
1099
1100AnyEvent::Fork itself cannot generally be used in subprocesses. As long as
1101only one process ever forks new processes, sharing the template processes
1102is possible (you could use a pipe as a lock by writing a byte into it to
1103unlock, and reading the byte to lock for example)
1104
1105To make concurrent calls possible after fork, you should get rid of the
1106template and early fork processes. AnyEvent::Fork will create a new
1107template process as needed.
1108
1109 undef $AnyEvent::Fork::EARLY;
1110 undef $AnyEvent::Fork::TEMPLATE;
1111
1112It doesn't matter whether you get rid of them in the parent or child after
1113a fork.
832 1114
833=head1 SEE ALSO 1115=head1 SEE ALSO
834 1116
835L<AnyEvent::Fork::Early> (to avoid executing a perl interpreter), 1117L<AnyEvent::Fork::Early>, to avoid executing a perl interpreter at all
1118(part of this distribution).
1119
836L<AnyEvent::Fork::Template> (to create a process by forking the main 1120L<AnyEvent::Fork::Template>, to create a process by forking the main
837program at a convenient time). 1121program at a convenient time (part of this distribution).
838 1122
839=head1 AUTHOR 1123L<AnyEvent::Fork::Remote>, for another way to create processes that is
1124mostly compatible to this module and modules building on top of it, but
1125works better with remote processes.
1126
1127L<AnyEvent::Fork::RPC>, for simple RPC to child processes (on CPAN).
1128
1129L<AnyEvent::Fork::Pool>, for simple worker process pool (on CPAN).
1130
1131=head1 AUTHOR AND CONTACT INFORMATION
840 1132
841 Marc Lehmann <schmorp@schmorp.de> 1133 Marc Lehmann <schmorp@schmorp.de>
842 http://home.schmorp.de/ 1134 http://software.schmorp.de/pkg/AnyEvent-Fork
843 1135
844=cut 1136=cut
845 1137
8461 11381
847 1139

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines