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

[David Blaikie]

On Thu, Aug 11, 2011 at 10:23 AM, Argyrios Kyrtzidis
<kyrtzidis at apple.com> wrote:
> 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);

minor optimization:
if (!OpenedHandles.insert(dlopen(filname).second)
  dlclose(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).

It'd be a pity if we couldn't make something more RAII-esque, though I
agree it's hard without movement support. I haven't looked closely -
but is there any (portable) way to duplicate a dynamic library handle?
In which case the copy ctor could just use that & the dtor could
dlclose & then we could return by value, etc, with relatively low
cost. (the only alternative, while preserving RAII-esque semantics, is
for the DynamicLibrary to remember what file/options it used & dlopen
on every copy (knowing it'll hit the OS's cache) which is probably
still pretty costly even for a cache hit)

- David