[EMAIL PROTECTED] 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. >
