Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 17 Jul 2001 10:33:15 -0700
From: Aaron Bannert <aaron@ebuilt.com>
To: Brian Pane <bpane@pacbell.net>
Cc: new-httpd@apache.org, dev@apr.apache.org
Subject: Re: Terminating threads in a process,
 WAS: RE: [PATCH] Problems with MPM threaded
Message-ID: <20010717103315.D23346@ebuilt.com>
References: <Pine.LNX.4.30.0107170856370.1421-100000@koj.rkbloom.net>
 <00d301c10edd$5a137370$93c0b0d0@roweclan.net> <3B546944.9070308@pacbell.net>
 <20010717094429.Y23346@ebuilt.com> <3B54730D.4070903@pacbell.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B54730D.4070903@pacbell.net>;
 from bpane@pacbell.net on Tue, Jul 17, 2001 at 10:17:01AM -0700

On Tue, Jul 17, 2001 at 10:17:01AM -0700, Brian Pane wrote:
> Aaron Bannert wrote:
> 
> >>I'm not sure that the alternative is workable, either.
> >>
> >>At the time of the fork, when the child process gets a snapshot of
> >>the parent's memory, it's possible that some thread other than the one
> >>invoking fork could be halfway through registering a new resource (e.g.,
> >>file descriptor) in its pool.  There's no guarantee that it's safe to
> >>attempt a cleanup of that other thread's pool in the child process;
> >>if the fork has caught the data structures in an intermediate state,
> >>attempting to destroy that pool might yield a segv.
> >>
> >
> >Correct me if I'm wrong, but that would be a property of a buggy MPM.
> >If the MPM chooses to mix non-synchronized fork()s and thread invocation,
> >than that's what it gets.
> >
> Synchronizing the forks with pool resource registration isn't a scalable
> design; it requires locking a process-wide lock every time you want to
> register a resource in a per-thread pool.  It would be a huge mistake
> to slow down the routine operation of the httpd in order to optimize for
> fork.

I wasn't suggesting that, I was suggesting that it's a bad idea to start
fork()ing off processes from an MPM that's also doing threads and you
want that fork()ed of process to later do cleanups.

My point is it's solely an MPM architecture decision. Are you saying that
this is a typical scenario?

-aaron