apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sander Striker" <stri...@apache.org>
Subject RE: Pools rewrite [2]
Date Tue, 11 Dec 2001 10:27:25 GMT
> From: Christian Gross [mailto:christiangross@yahoo.de]
> Sent: 11 December 2001 11:19

> At 22:12 04/12/2001 -0500, 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?
> >
> >--Cliff
> 
> Hi
> 
> I know I am harping in a bit late in the conversation...  BUT I really 
> wanted to add something here.  COM started with the same thing.  In COM 
> there are different threading models, which were created out of the need to 
> synchronize access and define ownership.  Likewise in Windows GUI code you 
> had the same situation.  In either case the problem's of having thread 
> owned stuff is that things become "quirky".  When I mean "quirky", I mean 
> gee it worked then, but not now.

A thread doesn't own any pools nor does it know about specific pools,
the same goes for the other way around.

The idea is to have to option to optimize for the situation where
you _know_ that a pool will only be accessed by one thread at a time.

The app is in control.  If you're not sure if you are using a pool
in more than one thread at a time, don't disable locking for that
pools allocator.

> So sorry about being a bit late on the topic...

No prob,
 
> Christian Gross

Sander

Mime
View raw message