perl-modperl mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tosh Cooey <>
Subject Re: Apache2::SubProcess sucks
Date Sun, 21 Feb 2010 16:02:58 GMT
Hey Torsten, I hope you don't think I was disparaging ( ) your help, I 
certainly wasn't and I want to thank you for it.  I was just lamenting 
on a lack of a clear simple example to use as a starting point, much 
like almost every programming language starts out with "Hello World" in 
the first chapter.

So yes, install ModPerl::Something and then use 
ModPerl::Something::Spawn would be great, and it could even come with 
some caveats on how leaving it like that could cause problems, and then 
people could use that as a starting point.

Anyway, I'm just waiting for a couple days with my simple solution in 
production to see if it causes any problems and then I'll post it here 
and try to get something that could be such a starting point.


Torsten Förtsch wrote:
> 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

McIntosh Cooey - Twelve Hundred Group LLC -

View raw message