Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Sun, 8 Jul 2001 23:23:56 -0700 (PDT)
From: dean gaudet <dean@arctic.org>
To: "Roy T. Fielding" <fielding@ebuilt.com>
cc: <new-httpd@apache.org>,  <apr-dev@apache.org>
Subject: Re: multithreaded pools?
In-Reply-To: <20010708223610.A912@waka.ebuilt.net>
Message-ID: <Pine.LNX.4.33.0107082315200.10441-100000@twinlark.arctic.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sun, 8 Jul 2001, Roy T. Fielding wrote:

> The last time I looked at the pool code it was bogus because clean_child_exit

how can clean_child_exit ever hope to work in a multithreaded server
without async notification?

in particular, what happens when modules start creating their own thread
pools within the server to do their own specific stuff?

i don't see how my change would make it any worse.  at least for the httpd
threads you know how to tell them all to finish up and die, and on the way
out they happen to destroy their pools.  so that handles all those new
pool roots.  (i'm not sure if clean_child_exit does this at all
currently.)

if clean_child_exit goes happily waltzing all over data in pools that are
in use by other threads without first killing the other threads then we're
just asking for segfaults, or even worse:  data corruption (such as
calling a cleanup on something which was unregistered).  there's race
conditions left and right.  you'd kind of have to lock everything
always... and then you'd have to deal with deadlocks on the way out of
clean_child_exit (not to mention a lack of performance).

-dean