httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: Context types in APR.
Date Mon, 03 May 1999 14:46:23 GMT

> I'm -1 on contexts until somebody can explain to me what they are for.
> I am NOT saying use pools as a junk yard, I'm accusing contexts
> of being a junk yard that is holding state that belongs elsewhere
> My position: if your going to add an additional parameter to every
> single routine in the system then you had better have a DAMN GOOD
> description of what it is.
> I've been thru every slot in this current proposal and shown they
> are unnessary, in most cases a mistake.  I now think this is just
> fuzzy thinking.
> All routines are methods on objects.  Those objects should contain 
> the state required or if not the state should be a parameter.

I'll try to clear things up a bit from my POV.  I don't see contexts as a
junk yard, I see them as aplace to control APR's behavior, and a place for
users to put their own data.

Some states are across objects.  For example, whether APR routines should
be cancelable for the current application.  In Apache, the answer is no
the programmer shouldn't be able to cancel a thread while it is in an APR
function.  This may not be true of other applications, or even of some
Apache modules (e.g.:  A module that spawns it's own process in the
initializer callback may want to be able to cancel it's own threads).  It
could be argued easily, that this belongs in the thread type, but then we
have to pass a thread to each apr function.  We are now back to where do
we put the thread pointer, in a pool or in a context.

But how about should an APR function be signal safe?  Where does that flag
belong.  It isn't really a thread decision, because we have
(un)block_alarms in the process-only Apache, and that is what this falg is
meant to replace. (The name may not be great, I haven't given the naming a
great deal of thought.)

Regardless of what we do, we HAVE to pass something to every apr function.
That something MUST have access to a pool pointer.  Without this, we will
be calling malloc/free combinations in APR, and that is a performance hit
I don't think we want to suffer.  If we can all agree that a pool must
somehow get to the APR layer, then we have to decide if it is the only
thing that must get into the APR layer, or if there is something else we
may want down there.  If there is something else we want to have in APR,
it is my opinion that adding that extra stuff to pools is the wrong way to

> > Ben also feels ALL apr types should allow users to hang their own data off
> > of them.
> Yes I do, except those that are always compile time constants.

I guess I am trying to figure out why anybody would want to hang data off
the directory structure, or the file structure.  The only one I can see
this being an issue for, is the thread structure (for thread local

> Would you argue that threads shouldn't have a place for users to hang
> additional state off of?

No.  I believe users do need a place in threads to hang their data.  I
haven't done ANY work with threads yet.  When I get to the thread stuff,
this will be put in place.

> In anycase it's a fair question.  Read the thread "Subject: tables
> with binary data.." in nh.9903.  It's a fine example of how much of
> pain it is when people design a data structure that spans some
> activity and they assume that the users of that data structure will
> have no need to annotate it with data specific to the task they are
> working on.  This is particularly true of data structures that have
> user defined call backs.

That's not a fair comparison IMO.  Tables are currently in APR, but they
were ported directly from the Apache code, so no more work was done on
them IIRC.  Most of the current APR code/work has been on creating a
run-time that allows us to use the same calls on different platforms.
Those data types don't need a place for users to hang their data off of in
most cases (threads being the most obvious exception).

I have yet to see a basic run-time library that allows users this option,
and I have yet to see a reason for putting it into most APR types.

> Currently when I write modules if I want to annotate the request, the
> connection, the uri, etc. etc. during my handling of the request I
> have to build out of band hash tables to do it.  Entirely because the
> core forgot to provide a place for me to store my mark ups on the task
> at hand.
> Since I'd argue that you can't predict which APR types will, in the
> fullness of time, have callback hooks invented for them then it's
> best to just put the a few bytes in all of them so users can refine
> them.

I guess it is my opinion that APR types, for the most part, should be
handled just like any other basic data type.  The are only more complex so
that they will work across platforms.

Of course, most of the thinking I have done aobut this topic has been in
regard to the APR repalcements for basic data types.  That is what I am
most concerned with, and that is the first step to getting the hybrid
Apache to finally be crosee-platform again.  The extra stuff that has come
from the Apache code, I haven' spent too much time thinking about, so
maybe I am missing something important there.  I just don't see a reason
to add user defined data types from the basic data structures.


Ryan Bloom
4205 S Miami Blvd	
RTP, NC 27709		It's a beautiful sight to see good dancers 
			doing simple steps.  It's a painful sight to
			see beginners doing complicated patterns.	

View raw message