httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <bh...@pobox.com>
Subject Re: Context types in apr
Date Fri, 30 Apr 1999 13:12:35 GMT
Ryan Bloom <rbb@raleigh.ibm.com> writes:

> > 
> > This is good, but I don't think it's just exactly 
> > right.
> > 
> > Every operation needs to have access to a pool.
> > Every operation needs to have access to the thread.
> 
> I'm not sure I agree with this second statement.  Why does a file open
> operation need access to a thread?  

Just to pick an example, operations need to be able to guard against 
thread destruction, i.e. the decendent of the current 
ap_{block,unblock}_alarms.

> I think a thread pointer would be the perfect thing to go into the
> programmer defined area.

I think there ought to be a place in all the apr data structures
for thier users to hand additional application specific data.
  See: <http://zap.ne.mediaone.net/p/p/properties/>

So there ought to be a APR API user area in pools, and in threads.

The design tangle here is exactly what the topology between the
apr data structures should be that is useful and necessary for
inside and outside apr.

> > Both threads and pools are used to encapsulate some
> > activity, so they look similar.  But pools should
> > be allowed to out number threads.
> 
> That was my original plan.  Although a context and thus a pool would be
> created for each pool

APR object, of course, all encapsulate some "activity".
We have a hierarchy of pools, and a hierarhcy of threads.
I think it's reasonably clear that branchs in the tree
of pools reside in nodes of the hierarhcy of threads.

I just can't see a difference between contexts and pools.

> it would be possible and in fact necessary that we
> have contexts that are not tied to pools.  The first thing any apr
> function should do is call apr_initialize, and that will create a context
> that isn't tied to any thread.  This context ends up being the parent
> context of all other contexts.

But it could just as well return the root pool and that pool
can give it access to the root thread.

> I think all of your ideas make sense for Apache, but I do not believe
> keeping a thread pointer in the pool on context itself is a good idea.  I
> was envisioning the base context (one without any user data) as a place
> for any flags or data structures that apr needs to modify it's behavior.

Like I say - I think all the operations need a pool and a thread.
They need the pool to get space, and they need the thread to get
the thread mux and to create fresh threads.

 - ben

---
"WARNING: Your operating system is unfamiliar." -- Bongo


Mime
View raw message