This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Subject: Re: efficient mod_perl alternatives to fork()? From: "Ken Williams" <ken@forum.swarthmore.edu> Date: Tue, 28 Nov 2000 21:38:55 -0600 ydbxmhc@yahoo.com (Paul) wrote: >I'm writing module code which (for backward compatibility with the CGI >it's replacing) needs to be able to execute commands from a file. >(~urgh~) The files have usually been ksh and/or Perl. Commonly, they >contain a directive to execute a line of shell script. > >Ideally, such commands will be replaced with equivelent perl code which >could simply be eval()'d, but I'm concerned that one of my coworkers >might write his perl code with backticks in it (like `grep foo *.bar`) >instead of writing the few extra lines of code, particularly since we >have a lot of legacy code in several languages (such as ksh functions). > >Wouldn't that effectively fork an entire server process before exec'ing >the qx//? And is there any simple way to prevent that, or any simple >alternative aside from a big stick? > >(a stoopid question -- Doesn't a Perl eval() with backticks do a full >blown program fork and exec, too?) No, eval() runs the code through the Perl interpreter in the same process, with full access to any variables that exist in the current scope. Any code run by eval() can, of course, fork, use backticks, run system calls, or do any number of other things that spawn sub-processes. But the eval() itself doesn't. See also http://perl.apache.org/guide/performance.html#Forking_and_Executing_Subprocess ===