[llvm-commits] [PATCH] Look up symbols in a specific library with DynamicLibrary

Argyrios Kyrtzidis kyrtzidis at apple.com
Thu Aug 11 10:23:18 PDT 2011


On Aug 11, 2011, at 9:56 AM, Jordy Rose wrote:

> 
> On Aug 11, 2011, at 8:30, Argyrios Kyrtzidis wrote:
> 
>> Hmm, I still don't see why DynamicLibrary needs to do refcount and not just be a thin wrapper over the handle (constructor will be private and will be only callable by DynamicLibrary's getPermanentLibrary; copy constructor has no issue).
>> Since the API states that the loading is permanent there's no need for refcounting.
> 
> The only way to acquire the handle is using dlopen, and that increments the internal refcount; with no destructor, it's never decremented. Unless we give up and make our own map. The code below shows the alternative of decrementing the refcount if we know it's greater than 1, but that's not particularly nice...
> 
> void *handle = dlopen(filename, [options]);
> if (OpenedHandles.contains(handle))
>  dlclose(handle);
> else
>  OpenHandles.insert(handle);
> return DynamicLibrary(handle);
> 
> ...but maybe it's the best alternative, bending but not breaking the contract.

This is indeed appropriate for our "we load them permanently and not unloading them" contract.

If we want to allow the client to unload libraries, I'd suggest that we provide a pair of loadLibrary/unloadLibrary functions (returning/accepting the thin DynamicLibrary wrapper) that do _not_ add the library in the permanently-loaded set.
It will be the responsibility of the caller to balance the library refcounts then. As David pointed out, you have to be careful when/where you are loading/unloading libraries so I'd stay away from RAII for this API (the client can certainly use it if it makes sense for his code).

> 
> Jordy




More information about the llvm-commits mailing list