apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: apr_dso_make??
Date Wed, 18 Apr 2001 23:05:44 GMT
On Wed, Apr 18, 2001 at 06:47:21PM +0100, David Reid wrote:
> Remind me again, why aren't we just going to add apr_dso_os_put (or whatever
> combination of the bits in the correct order is these days) and the _get
> version to use apr_os_dso_t's?  That *would* keep us in line with the rest
> of the APR API wouldn't it?

We discussed this a while back. The "put" forms actually don't make a lot of
sense. How do you make an empty FOO, so that you can put a native FOO into
it? As a result, the useful form is to "make" a FOO using a native object.

Hunh. Actually, it looks like the "put" forms are misnamed. They create an
object, rather than putting a native handle into an existing object.

Per the previous conversation, I'm +1 on renaming the "put" forms to "make".
The bootstrap problem of how to get a FOO means that "put" just isn't a
useful abstraction. Not to mention it leads to confusion like what we just
saw: you put into an existing apr_dso_handle_t, but put for files will
create a new file object.


Oh, crap. I just looked at unix/locks.c::apr_os_lock_put(). It expects the
user to do the whole "set to NULL before calling" thing. Damn, that style
was a source of bugs to no end (recall that file_open worked that way for a
while and bit us all the time).

I think it is confusing to do a "put" into an object. That can lead to
resource leaks (what happens to the previous native FOO?). I think it would
be best for us to drop all the "put" stuff, and stick with "get" and "make".



Greg Stein, http://www.lyra.org/

View raw message