=over

=item fork
X<fork> X<child> X<parent>

Does a L<fork(2)> system call to create a new process running the
same program at the same point.  It returns the child pid to the
parent process, C<0> to the child process, or L<C<undef>|/undef EXPR> if
the fork is
unsuccessful.  File descriptors (and sometimes locks on those descriptors)
are shared, while everything else is copied.  On most systems supporting
L<fork(2)>, great care has gone into making it extremely efficient (for
example, using copy-on-write technology on data pages), making it the
dominant paradigm for multitasking over the last few decades.

Perl attempts to flush all files opened for output before forking the
child process, but this may not be supported on some platforms (see
L<perlport>).  To be safe, you may need to set
L<C<$E<verbar>>|perlvar/$E<verbar>> (C<$AUTOFLUSH> in L<English>) or
call the C<autoflush> method of L<C<IO::Handle>|IO::Handle/METHODS> on
any open handles to avoid duplicate output.

If you L<C<fork>|/fork> without ever waiting on your children, you will
accumulate zombies.  On some systems, you can avoid this by setting
L<C<$SIG{CHLD}>|perlvar/%SIG> to C<"IGNORE">.  See also L<perlipc> for
more examples of forking and reaping moribund children.

Note that if your forked child inherits system file descriptors like
STDIN and STDOUT that are actually connected by a pipe or socket, even
if you exit, then the remote server (such as, say, a CGI script or a
backgrounded job launched from a remote shell) won't think you're done.
You should reopen those to F</dev/null> if it's any issue.

On some platforms such as Windows, where the L<fork(2)> system call is
not available, Perl can be built to emulate L<C<fork>|/fork> in the Perl
interpreter.  The emulation is designed, at the level of the Perl
program, to be as compatible as possible with the "Unix" L<fork(2)>.
However it has limitations that have to be considered in code intended
to be portable.  See L<perlfork> for more details.

Portability issues: L<perlport/fork>.

=back