|
|
1 | NAME |
|
|
2 | Proc::FastSpawn - fork+exec, or spawn, a subprocess as quickly as |
|
|
3 | possible |
|
|
4 | |
|
|
5 | SYNOPSIS |
|
|
6 | use Proc::FastSpawn; |
|
|
7 | |
|
|
8 | DESCRIPTION |
|
|
9 | The purpose of this small (in scope and footprint) module is simple: |
|
|
10 | spawn a subprocess asynchronously as efficiently and/or fast as |
|
|
11 | possible. Basically the same as calling fork+exec (on POSIX), but |
|
|
12 | hopefully faster than those two syscalls. |
|
|
13 | |
|
|
14 | Apart from fork overhead, this module also allows you to fork+exec |
|
|
15 | programs when otherwise you couldn't - for example, when you use POSIX |
|
|
16 | threads in your perl process then it generally isn't safe to call fork |
|
|
17 | from perl, but it is safe to use this module to execute external |
|
|
18 | processes. |
|
|
19 | |
|
|
20 | If neither of these are problems for you, you can safely ignore this |
|
|
21 | module. |
|
|
22 | |
|
|
23 | So when is fork+exec not fast enough, how can you do it faster, and why |
|
|
24 | would it matter? |
|
|
25 | |
|
|
26 | Forking a process requires making a complete copy of a process. Even |
|
|
27 | thougth almost every implementation only copies page tables and not the |
|
|
28 | memory istelf, this is still not free. For example, on my 3.6GHz amd64 |
|
|
29 | box, I can fork a 5GB process only twenty times a second. For a realtime |
|
|
30 | process that must meet stricter deadlines, this is too slow. For a busy |
|
|
31 | and big webserver, starting CGI scripts might mean unacceptable |
|
|
32 | overhead. |
|
|
33 | |
|
|
34 | A workaround is to use "vfork" - this function isn't very portable, but |
|
|
35 | it avoids the memory copy that "fork" has to do. Some systems have an |
|
|
36 | optimised implementation of "spawn", and some systems have nothing. |
|
|
37 | |
|
|
38 | This module tries to abstract these differences away. |
|
|
39 | |
|
|
40 | As for what improvements to expect - on the 3.6GHz amd64 box that this |
|
|
41 | module was originally developed on, a 3MB perl process (basically just |
|
|
42 | perl + Proc::FastSpawn) takes 3.6s to run /bin/true 10000 times using |
|
|
43 | fork+exec, and only 2.6s when using vfork+exec. In a 22MB process, the |
|
|
44 | difference is already 5.0s vs 2.6s, and so on. |
|
|
45 | |
|
|
46 | FUNCTIONS |
|
|
47 | All the following functions are currently exported by default. |
|
|
48 | |
|
|
49 | $pid = spawn $path, \@argv[, \@envp] |
|
|
50 | Creates a new process and tries to make it execute $path, with the |
|
|
51 | given arguments and optionally the given environment variables, |
|
|
52 | similar to calling fork + execv, or execve. |
|
|
53 | |
|
|
54 | Returns the PID of the new process if successful. On any error, |
|
|
55 | "undef" is currently returned. Failure to execution might or might |
|
|
56 | not be reported as "undef", or via a subprocess exit status of 127. |
|
|
57 | |
|
|
58 | fd_inherit $fileno[, $on] |
|
|
59 | File descriptors can be inherited by the spawned proceses or not. |
|
|
60 | This is decided on a per file descriptor basis. This module does |
|
|
61 | nothing to any preexisting handles, but with this call, you can |
|
|
62 | change the state of a single file descriptor to either be inherited |
|
|
63 | ($on is true or missing) or not $on is false). |
|
|
64 | |
|
|
65 | PORTABILITY NOTES |
|
|
66 | On POSIX systems, this module currently calls vfork+exec, spawn, or |
|
|
67 | fork+exec, depending on the platform. If your platform has a good vfork |
|
|
68 | or spawn but is misdetected and falls back on slow fork+exec, drop me a |
|
|
69 | note. |
|
|
70 | |
|
|
71 | On win32, the "_spawn" family of functions is used, and the module tries |
|
|
72 | hard to patch the new process into perl's internal pid table, so the pid |
|
|
73 | returned should work with other perl functions such as waitpid. Also, |
|
|
74 | win32 doesn't have a meaningful way to quote arguments containing |
|
|
75 | "special" characters, so this module tries it's best to quote those |
|
|
76 | strings itself. Other typical platform limitations (such as being able |
|
|
77 | to only have 64 or so subprocesses) apply as well. |
|
|
78 | |
|
|
79 | AUTHOR |
|
|
80 | Marc Lehmann <schmorp@schmorp.de> |
|
|
81 | http://home.schmorp.de/ |
|
|
82 | |
