Penguin
Recent Changes
Annotated edit history of perlfork(1) version 2, including all changes. View license author blame.
Rev Author # Line
1 perry 1 PERLFORK
2 !!!PERLFORK
3 NAME
4 SYNOPSIS
5 DESCRIPTION
6 BUGS
7 AUTHOR
8 SEE ALSO
9 ----
10 !!NAME
11
12
13 perlfork - Perl's ''fork()'' emulation ( EXPERIMENTAL , subject to change)
14 !!SYNOPSIS
15
16
17 WARNING: As of the 5.6.1 release, the fork() emulation continues
18 to be an experimental feature. Use in production applications is
19 not recommended. See the
20 Perl provides a ''fork()'' keyword that corresponds to the Unix system call of the same name. On most Unix-like platforms where the ''fork()'' system call is available, Perl's ''fork()'' simply calls it.
21
22
23 On some platforms such as Windows where the ''fork()''
24 system call is not available, Perl can be built to emulate
25 ''fork()'' at the interpreter level. While the emulation
26 is designed to be as compatible as possible with the real
27 ''fork()'' at the level of the Perl program, there are
28 certain important differences that stem from the fact that
29 all the pseudo child ``processes'' created this way live in
30 the same real process as far as the operating system is
31 concerned.
32
33
34 This document provides a general overview of the
35 capabilities and limitations of the ''fork()'' emulation.
36 Note that the issues discussed here are not applicable to
37 platforms where a real ''fork()'' is available and Perl
38 has been configured to use it.
39 !!DESCRIPTION
40
41
42 The ''fork()'' emulation is implemented at the level of
43 the Perl interpreter. What this means in general is that
44 running ''fork()'' will actually clone the running
45 interpreter and all its state, and run the cloned
46 interpreter in a separate thread, beginning execution in the
47 new thread just after the point where the ''fork()'' was
48 called in the parent. We will refer to the thread that
49 implements this child ``process'' as the
50 pseudo-process.
51
52
53 To the Perl program that called ''fork()'', all this is
54 designed to be transparent. The parent returns from the
55 ''fork()'' with a pseudo-process ID that
56 can be subsequently used in any process manipulation
57 functions; the child returns from the ''fork()'' with a
58 value of 0 to signify that it is the child
59 pseudo-process.
60
61
62 __Behavior of other Perl features in forked
63 pseudo-processes__
64
65
66 Most Perl features behave in a natural way within
67 pseudo-processes.
68
69
70 $$ or $PROCESS_ID
71
72
73 This special variable is correctly set to the pseudo-process
74 ID . It can be used to identify
75 pseudo-processes within a particular session. Note that this
76 value is subject to recycling if any pseudo-processes are
77 launched after others have been ''wait()''-ed
78 on.
79
80
81 %ENV
82
83
84 Each pseudo-process maintains its own virtual environment.
85 Modifications to %ENV affect the virtual
86 environment, and are only visible within that
87 pseudo-process, and in any processes (or pseudo-processes)
88 launched from it.
89
90
91 ''chdir()'' and all other builtins that accept
92 filenames
93
94
95 Each pseudo-process maintains its own virtual idea of the
96 current directory. Modifications to the current directory
97 using ''chdir()'' are only visible within that
98 pseudo-process, and in any processes (or pseudo-processes)
99 launched from it. All file and directory accesses from the
100 pseudo-process will correctly map the virtual working
101 directory to the real working directory
102 appropriately.
103
104
105 ''wait()'' and ''waitpid()''
106
107
108 ''wait()'' and ''waitpid()'' can be passed a
109 pseudo-process ID returned by ''fork()''.
110 These calls will properly wait for the termination of the
111 pseudo-process and return its status.
112
113
114 ''kill()''
115
116
117 ''kill()'' can be used to terminate a pseudo-process by
118 passing it the ID returned by ''fork()''.
119 This should not be used except under dire circumstances,
120 because the operating system may not guarantee integrity of
121 the process resources when a running thread is terminated.
122 Note that using ''kill()'' on a pseudo-''process()''
123 may typically cause memory leaks, because the thread that
124 implements the pseudo-process does not get a chance to clean
125 up its resources.
126
127
128 ''exec()''
129
130
131 Calling ''exec()'' within a pseudo-process actually
132 spawns the requested executable in a separate process and
133 waits for it to complete before exiting with the same exit
134 status as that process. This means that the process
135 ID reported within the running executable
136 will be different from what the earlier Perl ''fork()''
137 might have returned. Similarly, any process manipulation
138 functions applied to the ID returned by
139 ''fork()'' will affect the waiting pseudo-process that
140 called ''exec()'', not the real process it is waiting for
141 after the ''exec()''.
142
143
144 ''exit()''
145
146
147 ''exit()'' always exits just the executing
148 pseudo-process, after automatically ''wait()''-ing for
149 any outstanding child pseudo-processes. Note that this means
150 that the process as a whole will not exit unless all running
151 pseudo-processes have exited.
152
153
154 Open handles to files, directories and network
155 sockets
156
157
158 All open handles are ''dup()''-ed in pseudo-processes, so
159 that closing any handles in one process does not affect the
160 others. See below for some limitations.
161
162
163 __Resource limits__
164
165
166 In the eyes of the operating system, pseudo-processes
167 created via the ''fork()'' emulation are simply threads
168 in the same process. This means that any process-level
169 limits imposed by the operating system apply to all
170 pseudo-processes taken together. This includes any limits
171 imposed by the operating system on the number of open file,
172 directory and socket handles, limits on disk space usage,
173 limits on memory size, limits on CPU
174 utilization etc.
175
176
177 __Killing the parent process__
178
179
180 If the parent process is killed (either using Perl's
181 ''kill()'' builtin, or using some external means) all the
182 pseudo-processes are killed as well, and the whole process
183 exits.
184
185
186 __Lifetime of the parent process and
187 pseudo-processes__
188
189
190 During the normal course of events, the parent process and
191 every pseudo-process started by it will wait for their
192 respective pseudo-children to complete before they exit.
193 This means that the parent and every pseudo-child created by
194 it that is also a pseudo-parent will only exit after their
195 pseudo-children have exited.
196
197
198 A way to mark a pseudo-processes as running detached from
199 their parent (so that the parent would not have to
200 ''wait()'' for them if it doesn't want to) will be
201 provided in future.
202
203
204 __CAVEATS AND LIMITATIONS__
205
206
207 BEGIN blocks
208
209
210 The ''fork()'' emulation will not work entirely correctly
211 when called from within a BEGIN block. The
212 forked copy will run the contents of the
213 BEGIN block, but will not continue parsing
214 the source stream after the BEGIN block. For
215 example, consider the following code:
216
217
218 BEGIN {
219 fork and exit; # fork child and exit the parent
220 print
221 This will print:
222
223
224 inner
225 rather than the expected:
226
227
228 inner
229 outer
230 This limitation arises from fundamental technical difficulties in cloning and restarting the stacks used by the Perl parser in the middle of a parse.
231
232
233 Open filehandles
234
235
236 Any filehandles open at the time of the ''fork()'' will
237 be ''dup()''-ed. Thus, the files can be closed
238 independently in the parent and child, but beware that the
239 ''dup()''-ed handles will still share the same seek
240 pointer. Changing the seek position in the parent will
241 change it in the child and vice-versa. One can avoid this by
242 opening files that need distinct seek pointers separately in
243 the child.
244
245
246 Forking pipe ''open()'' not yet implemented
247
248
249 The open(FOO, and open(BAR,
250 constructs are not yet implemented. This
251 limitation can be easily worked around in new code by
252 creating a pipe explicitly. The following example shows how
253 to write to a forked child:
254
255
256 # simulate open(FOO,
257 if (pipe_to_fork('FOO')) {
258 # parent
259 print FOO
260 And this one reads from the child:
261
262
263 # simulate open(FOO,
264 if (pipe_from_fork('BAR')) {
265 # parent
266 while (
267 Forking pipe ''open()'' constructs will be supported in future.
268
269
270 Global state maintained by XSUBs
271
272
273 External subroutines (XSUBs) that maintain their own global
274 state may not work correctly. Such XSUBs will either need to
275 maintain locks to protect simultaneous access to global data
276 from different pseudo-processes, or maintain all their state
277 on the Perl symbol table, which is copied naturally when
278 ''fork()'' is called. A callback mechanism that provides
279 extensions an opportunity to clone their state will be
280 provided in the near future.
281
282
283 Interpreter embedded in larger application
284
285
286 The ''fork()'' emulation may not behave as expected when
287 it is executed in an application which embeds a Perl
288 interpreter and calls Perl APIs that can evaluate bits of
289 Perl code. This stems from the fact that the emulation only
290 has knowledge about the Perl interpreter's own data
291 structures and knows nothing about the containing
292 application's state. For example, any state carried on the
293 application's own call stack is out of reach.
294
295
296 Thread-safety of extensions
297
298
299 Since the ''fork()'' emulation runs code in multiple
300 threads, extensions calling into non-thread-safe libraries
301 may not work reliably when calling ''fork()''. As Perl's
302 threading support gradually becomes more widely adopted even
303 on platforms with a native ''fork()'', such extensions
304 are expected to be fixed for thread-safety.
305 !!BUGS
306
307
308 Perl's regular expression engine currently does not play
309 very nicely with the ''fork()'' emulation. There are
310 known race conditions arising from the regular expression
311 engine modifying state carried in the opcode tree at run
312 time (the ''fork()'' emulation relies on the opcode tree
313 being immutable). This typically happens when the regex
314 contains paren groups or variables interpolated within it
315 that force a run time recompilation of the regex. Due to
316 this major bug, the ''fork()'' emulation is not
317 recommended for use in production applications at this
318 time.
319
320
321 Having pseudo-process IDs be negative integers breaks down
322 for the integer -1 because the ''wait()'' and
323 ''waitpid()'' functions treat this number as being
324 special. The tacit assumption in the current implementation
325 is that the system never allocates a thread
326 ID of 1 for user threads. A better
327 representation for pseudo-process IDs will be implemented in
328 future.
329
330
331 This document may be incomplete in some
332 respects.
333 !!AUTHOR
334
335
336 Support for concurrent interpreters and the ''fork()''
2 perry 337 emulation was implemented by !ActiveState, with funding from
1 perry 338 Microsoft Corporation.
339
340
341 This document is authored and maintained by Gurusamy Sarathy
342 !!SEE ALSO
343
344
345 ``fork'' in perlfunc, perlipc
346 ----
This page is a man page (or other imported legacy content). We are unable to automatically determine the license status of this page.