Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3C0DA281.7030509@cnet.com>
Date: Tue, 04 Dec 2001 20:28:49 -0800
From: Brian Pane <brian.pane@cnet.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:0.9.5) Gecko/20011011
MIME-Version: 1.0
To: dev@apr.apache.org
Subject: Re: Pools rewrite [2]
References: <Pine.GSO.4.32.0112042208090.15453-100000@cobra.cs.Virginia.EDU>
 <3C0D9259.2000200@cnet.com> <006701c17d40$69a3b580$01000100@sashimi>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Bill Stoddard wrote:

[...]

>>If a future async implementation has this same property--i.e.,
>>pools can be "passed" from one thread to another, but a given
>>pool can only have its methods invoked from one thread at a
>>time--then we shouldn't have any problems.
>>
>>--Brian
>>
>
>What happens if a thread exits (under shutdown for instance) and requests are still being
>handled by other threads asynchrounously? Looks as if that threads cleanup will free the
>pool out from under the thread using the pool at the time.
>

Right, although that problem isn't specific to the freelist.  In
the scenario you're describing, any resource inside the pool, like
an mmap or a file descriptor,  could get clobbered by the thread
that owns the pool while another thread is simultaneously trying to
complete the request associated with the pool.

I think the implication of this is that, in the async model, the
thread that creates a pool for a transaction shouldn't be considered
the owner of the pool--and thus shouldn't take responsibility for
destroying the pool during shutdown.  I look at that as a design
challenge for an async MPM, rather than something that the pools
themselves can solve.

--Brian