Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Content-Type: text/plain;
  charset="iso-8859-1"
From: Ryan Bloom <rbb@covalent.net>
Reply-To: rbb@covalent.net
Organization: Covalent Technologies
To: "Bill Stoddard" <bill@wstoddard.com>,
	"Brian Pane" <brian.pane@cnet.com>, <dev@apr.apache.org>
Subject: Re: Pools rewrite [2]
Date: Tue, 4 Dec 2001 21:01:27 -0800
References: <Pine.GSO.4.32.0112042208090.15453-100000@cobra.cs.Virginia.EDU>
 <3C0D9259.2000200@cnet.com> <006701c17d40$69a3b580$01000100@sashimi>
In-Reply-To: <006701c17d40$69a3b580$01000100@sashimi>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <20011205050128.8B69946E02@koj.rkbloom.net>

On Tuesday 04 December 2001 07:53 pm, Bill Stoddard wrote:
> > Cliff Woolley wrote:
> > >>This is my second go at the pools code.
> > >
> > >A potential snag with the thread-specific pools idea was brought up
> > > today when I was talking with FirstBill and some of the others.  What
> > > is this going to do to us a little ways down the road when we try to
> > > implement async I/O, and all of the sudden requests are jumping from
> > > one thread to another?  Sounds like a big problem if thread-specific
> > > pools are in place... is there an easy answer?
> >
> > I think there's an easy answer.
> >
> > The thread-specific pools in this implementation are really
> > just pools that happen to own their own free lists.  If those
> > pools get moved from one thread to another, that's okay, as
> > long as only one thread at a time is accessing a given pool
> > (which has always been a restriction of the pool API, because
> > apr_palloc() isn't thread-safe).  In fact, we have this scenario
> > already in the worker MPM with Sander's pool code: the
> > thread-specific pool for each request gets created by the
> > listener thread and handed off to a worker thread.
> >
> > 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.

Yeah, but that is only because the pool was allocated out of the thread pool,
and if we are really working on async, it would have to be allocated out
of the child_pool.  That would solve that problem.

Ryan

______________________________________________________________
Ryan Bloom				rbb@apache.org
Covalent Technologies			rbb@covalent.net
--------------------------------------------------------------