[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: dso alternative

From: Greg Stein <gstein_at_lyra.org>
Date: 2000-12-13 23:57:04 CET

On Wed, Dec 13, 2000 at 04:14:28PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
>
> > Calling apr_dso_load() multiple times, within a process, for the same DSO
> > should be quite fine.
>
> OK, then I should keep things as simple as possible.
>
> I'm going to have a function which takes a URL as input, and returns a
> vtable from a RA DSO load. A single process might call this function
> over and over -- that's okay, according to what you say above. (When
> a process reloads the same DSO over and over, the OS gives it the same
> pointer each time, right?)

You get the same apr_dso_handle_t each time. Presumably, the result of
apr_dso_sym() will be the same pointer each time, too. And the OS refcounts
the bugger (keeping in in memory until the Nth unload() call, where N ==
#loads).

Strictly speaking, I don't know that it matters since you're just returning
them each time (rather than caching/storing them).

> So forget threads. I was only worried about writing "threadsafe"
> code. But now that I won't have any global variables, the issue is
> moot. There's no need for a global hash of loaded dso's.

Ah. Good point. Quite cool.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:17 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.