httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Hyde <>
Subject Re: Context types in APR.
Date Fri, 07 May 1999 19:57:21 GMT
Manoj Kasichainula <> writes:

> BTW, I'm wary of this whole context idea, but Ken is slowly convincing
> me.
> On Fri, May 07, 1999 at 01:06:17PM -0400, Ben Hyde wrote:
> > No?  It would seem to me that you only need to pass a pool
> > to those functions that create objects for the API.  For example
> > 
> >     obj = apr_obj_create(p, ...);
> > 
> > Operations that return fresh data structures should always take
> > an explicit pool since the caller should decided what pool they
> > belong in.
> The main problem here is that there might be APR functions that take
> no APR-created arguments. I didn't believe this was even possible
> until Ken mentioned the canonical_filename stuff. This is definitely a
> portability layer piece, and if demonical_filename retains its current
> form, then it will take a string and return a string. How do we
> support such an operation unless we pass in a pool/context?

Sure, there might be a problem with operations on things too simple
to have the overhead of object, but these operations can take the pool.

> There are answers of course. One is to make sure you *always* operate
> on APR-created objects. In the case of demonical_filename, create
> apr_string_t and do all our string operations through it. Qt does
> this, and I don't like it.

The design pattern where some suites of operations take a manager_object
for the class of things they are working on hasn't arisen in Apache
to date.  This usually arises because you want a set, say of already
established connections to the database server.  Sometimes people do
it just to get what we already have with pools a nice memory management
scheme.  So I wouldn't think that it would be necessary to create a
string_manager thingy and pass it around, but yeah pass a pool if there
is any chance the operation will need space.

> Another answer is to handle files like Java does, which is to create a
> Filename object (called File in Java) which is created from the string
> of the filename. Then, demonical_filename would operate on this
> Filename object, and so would all the APR file I/O routines. Is this
> an acceptable solution for every case that resembles
> demonical_filename? I personally don't mind it, but I'm sure others
> will scream loudly.

If you need an object, make it.  Creating a wild card object doesn't
reduce in any interesting way the cases that need one.

 - ben

View raw message