Return-Path: Delivered-To: apache-bugdb-archive@hyperreal.org Received: (qmail 15076 invoked by uid 6000); 3 Jun 1998 18:10:05 -0000 Received: (qmail 15012 invoked by uid 2001); 3 Jun 1998 18:10:00 -0000 Date: 3 Jun 1998 18:10:00 -0000 Message-ID: <19980603181000.15011.qmail@hyperreal.org> To: apache-bugdb@apache.org Cc: apache-bugdb@apache.org, From: Marc Slemko Subject: Re: apache-api/2337: Modules are initialized twice at startup. Reply-To: Marc Slemko Sender: apache-bugdb-owner@apache.org Precedence: bulk The following reply was made to PR apache-api/2337; it has been noted by GNATS. From: Marc Slemko To: Martin Lichtin Cc: Apache bugs database Subject: Re: apache-api/2337: Modules are initialized twice at startup. Date: Wed, 3 Jun 1998 09:55:42 -0700 (PDT) On Wed, 3 Jun 1998, Martin Lichtin wrote: > Ben Laurie writes: > > The justification I was given, a long time ago, was that modules are > > reinitialised on a server restart (i.e. SIGHUP or SIGUSR1) so they may > > as well go wrong at startup if they can't deal with that. I believe that > > that is just a rationalisation, though. The real reason is that it is > > simpler to let it do it that way. > > Ok, but why then does the SSL patch subvert that behaviour? One > problem, for example, is that the FastCGI module expects to be called > twice at startup, but after the SSL patch, this is not true anymore so > it fails to initialize itself. It took me some time to figure that out. > > In general, module initialization can be costly, so Apache shouldn't > initialize all its modules twice at startup, there's just no reason > for it, as far as I can see. > And we do not want to mess with the way it is done now because, as you say, it creates problems for numerous modules. It was tried in one beta. It caused so many problems we had to go back. In 2.0, this will likely be revisited.