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_handle_close ?
Date Tue, 17 Apr 2001 06:36:28 GMT
Let's just have:

  apr_dso_make(apr_dso_handle_t **h, void *plat_hand, apr_pool_t *p);

I know that Doug wants to do something like:

    apr_dso_make(&h, p);
    apr_dso_fill(h, handle1);
    apr_dso_unload(h);
    apr_dso_fill(h, handle2);
    apr_dso_unload(h);
    apr_dso_fill(h, handle3);
    apr_dso_unload(h);

But I'd say:

    sub = apr_create_pool(p);
    apr_dso_make(&h, handle1, sub);
    apr_dso_unload(h);
    apr_dso_make(&h, handle2, sub);
    apr_dso_unload(h);
    apr_dso_make(&h, handle3, sub);
    apr_dso_unload(h);
    apr_pool_destroy(sub);

That keeps our API simpler. If somebody doesn't want to care about memory so
much, then the subpool isn't even needed. As I mentioned before, if you're
tossing DSO's, I bet there is a pool that is getting tossed, too (so the
apr_dso_make memory can go in there for a short period).

Heck, I just realized. This is even cleaner:

    sub = apr_create_pool(p);
    apr_dso_make(&h, handle1, sub);
    apr_dso_make(&h, handle2, sub);
    apr_dso_make(&h, handle3, sub);
    apr_pool_destroy(sub);

Since DSO's go away with the pool they're registered in, the above will toss
all the DSOs at pool destruction. Of course, you don't get error feedback
from each unload(), but it all depends on whether you even *want* it.

Anyhow... let's have just a single apr_dso_make(). I don't need a need for
two functions.

Cheers,
-g

On Mon, Apr 16, 2001 at 03:03:11PM -0700, rbb@covalent.net wrote:
> 
> Okay,  this issue has died down now, so it is time to bring it back up,
> with a potential solution.  Doug and I have already discussed this, and he
> agrees that this solves his problem.  It also solves the other problems
> that have been raised on this list.
> 
> My biggest problem with passing in a void *, and using it as the dlhandle
> to close, is that it won't work in error cases on some platforms.  OS/2
> requires that we save the error message when the error happens, at least
> that is my understanding.  This means that if there is an error, we will
> need to store that string someplace.
> 
> My solution:
> 
>    two functions:
> 	apr_dso_make(apr_dso_handle_t **h, apr_pool_t *p);
> 		Allocate enough space for an apr_dso_handle_t
> 	apr_dso_fill(apr_dso_handle_t *h, void *plat_hand);
> 		Fill the handle out.
> 
>    Now, programs can safely use apr_dso_close on the resulting
> apr_dso_handle_t, and we don't lose portability.  They can also
> re-use the original apr_dso_handle_t until they are done closing
> DSOs.  There is a large part of me that would like to see us use this
> model for all of the portability code that we have.
> 
> Unless there are any arguments, I will be implementing this on some
> platforms tomorrow sometime.
> 
> Ryan
> 
> 
> On Mon, 9 Apr 2001 rbb@covalent.net wrote:
> 
> >
> > The problem is that the code you want to implement is incompatible with
> > APR's dso code.  In order to use the function that you want, you would
> > need to start by using the system's dlopen.  If you are going to use the
> > systems dlopen, then you should use the systems dlclose.
> >
> > What we really need, I guess, is apr_dso_put and apr_dso_get.  That would
> > follow the model that we currently have, instead of creating another
> > function that would take the system type directly.
> >
> > Ryan
> >
> > On Mon, 9 Apr 2001, Doug MacEachern wrote:
> >
> > > On Mon, 9 Apr 2001 rbb@covalent.net wrote:
> > >
> > > >
> > > > How is this different from apr_dso_unload?
> > >
> > > apr_dso_unload() takes an apr_dso_handle_t argument, so i would have todo
> > > something ugly like:
> > >
> > > apr_dso_handle_t dso;
> > > dso.handle = (void*)handle_from_perl;
> > > dso.cont = p;
> > > apr_dso_unload(&dso);
> > >
> > > which i couldn't do if i wanted to, since apr_dso_handle_t is an
> > > incomplete type.
> > >
> > >
> > >
> >
> >
> > _______________________________________________________________________________
> > Ryan Bloom                        	rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
> >
> >
> 
> 
> _______________________________________________________________________________
> Ryan Bloom                        	rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------

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

Mime
View raw message