> > I disagree completely. The Windows MPM is fragile, because it is almost > > impossible to read. Bill has been cleaning it up so that multiple > > people can easily modify the code and actually understand what is > > happening. > > > > Knowing how much time Bill has spent reading through that code, and > > trying to solve the underlying problem, I know that he believes he must > > clean the code before he can fix the actual bug. > > > > Ryan > > > > I suggest spending time to learn about code before you begin hacking it > up. I've seen > this exact same pattern repeat itself in Apache 2.0 multiple times. You > and Bill have a > grand vision of 'how things should be', and start making changes. When you > are done, what > once worked is broken and others are left to pick up the pieces and finish > what you > started. Both you guys have done some really good things, don't get me > wrong, but I am > frankly tired of picking up after you guys. > > When I stopped work on the windows MPM, everything worked. I leave it > alone for several > months, you guys come in and start changing things and you f*cked it up. A > bit of testing > after every change would have caught the bug when it was first introduced. > It's not too > much to ask that yuou finish what you start and understand what you are > changing before > you change it. You CANNOT argue you did this with the Windows MPM, because > clearly you did > not.
BS I didn't test. I did test. I ran the server for three days after making my changes. In fact, Bill was harping on my to commit the damn patch because I was taking so long to get it in. The problem was that I didn't realize how fragile the damn service stuff was. Nor could I have, because there was no comment explaining what was happening. Add to that, the Windows MPM didn't behave like any other MPM. That means that as people were writing modules for Windows, they were adding hacks to their modules to make up for the way that the MPM did things. That is completely bogus. What I did was to move the Windows MPM back into line with the other MPMs with regard to the pre_mpm hook, so that it was very clearly stated that the pre_mpm hook is called once per Apache instance and the child_init hook is called once per child process. What Bill is doing is cleaning the code so that it looks like other Apache modules and can be followed. Does this mean that he is ripping the module apart and putting it back together? Yes, because that is what is required to understand the damn thing. As for the fact that the Windows MPM was working before we touched it and wasn't working afterwards, I don't believe it. I believe that the changes we made highlighted problems that weren't hitting due to luck before. Do I have proof? How about the fact that all I did was relocate code that was already in the server? I didn't add a single line of code, nor did I remove one. I just moved it from the pre_mpm phase to the child_init phase, which was not all that different at the end of the day. Ryan
