On Saturday 20 February 2010 19:25:39 Tosh Cooey wrote: > I do enjoy the fact that nobody really seems to have a simple definitive > vanilla fork/spawn process down pat, it seems everyone does what I do, > trying this and that stumbling about until they come up with some > monstrosity like Torsen has that works under the sheer weight of tricks. > Well, if I'd said: "Tosh take ModPerl::Something from CPAN and call ModPerl::Something::spawn" you'd liked it (no matter what it does internally), right?
That sheer weight of tricks comes down to 3 points: - you have to close the client socket in the child process or the browser will wait for more data - if your process should survive an apache restart it must create its own process group, hence the setsid(). - accidental leaking file descriptors to child processes is generally considered a security hole This is what my function does, it closes all file descriptors except for STDERR and calls setsid, nothing special. Perhaps it would be good to reopen STDIN and STDOUT as /dev/null because many programs don't like closed STDIN/STDOUT but again, no tricks. A tricky part would be to really restore the normal Perl environment if you don't want to exec() another program but simply to call a Perl function. Reverting the effect of *CORE::GLOBAL::exit=\&ModPerl::Util::exit in an already compiled function, that is tricky. Or reestablish the connection between %ENV and C-level char *environ[]. Torsten
