httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@apache.org>
Subject Re: Perchild works again.... kind of
Date Sun, 18 Aug 2002 16:05:34 GMT
rbb@apache.org wrote:
> Below is the commit message that I just msent for the perchild MPM.  This
> MPM works again, but it still doesn't work well.  Currently, I have used
> it to pass requests between processes, but it just isn't clean at all.  I
> have had random failures, and I don't recommend putting this MPM into
> production at all.
> 
> Hopefully in the next day or two I will have time to document how this MPM
> works, and I will have time to go through and continue to scrub this code
> and make it cleaner.
> 
> It is unlikely that I will do much more work on the code itself for the
> next few weeks, because I only have access to a Linux box
> currently.  Unfortunately, this is a threaded MPM, by definition, and
> debugging threads on Linux is the most painful thing you can do.  I will
> be setting up an x86 Solaris machine soon though, and I will be able to
> use that box to debug this MPM.  In the meantime, if anybody has a Solaris
> box that I can get access to, I would be more than happy to continue to
> fix bugs in this MPM.

sourceforge.net has 2-3 solaris boxes you can you to build/test on in 
their compilefarm if that helps
> 
> Hopefully, more commits tomorrow.
> 
> Ryan
> 
> 
> rbb         2002/08/17 23:05:48
> 
>   Modified:    server/mpm/experimental/perchild perchild.c
>   Log:
>   This commit gets Perchild working again.  There are holes in this code
>   big enough to drive a truck through, and it is NOT production quality,
>   but I have successfully passed file descriptors between processes and
>   served requests over the passed descriptors.  This code needs documenting,
>   and vetting still.
>   
>   Also, in order to make things work, I had to insert the socket and the
>   data read by the original process into the bottom of the filter stack so
>   that the new process could use that information.  Unfortunately, that isn't
>   possible to do cleanly, so I search for the CORE_IN filter, and I insert
>   a brigade that I have created into it's ctx pointer.  This is a hack, and
>   it means that Perchild _only_ works if you use the core filters.  Until I
>   find a better way to get that information to the bottom of the filter
>   stack, that is just how it is going to be.
> 



Mime
View raw message