On Aug 4, 2011, at 1:04 PM, Lubos Lunak wrote:
> On Wednesday 03 of August 2011, Caolán McNamara wrote:
>> On Tue, 2011-08-02 at 14:58 +0200, Lubos Lunak wrote:
>>> - osl_loadModule*() functions are plain C functions from stable API, so
>>> no overloading to add the extra argument for the error message, the best
>>> I've come up with was simply a wrapper around dlerror(), which I admit is
>>> not very nice API either, would there be any better approach?
>>
>> Has the obvious issue of an gap between error and retrieving the error
>> and some other thread churning away in between, how about...
>
> That's already inherent in dlerror() itself, I have no idea how this is
> handled on Windows.
>
>> A oslModule is a void* and we're currently just directly casting the
>> return from dlopen (and the windows equivalent) to a oslModule
>>
>> Maybe one possibility is instead a private struct like
>>
>> struct unx_impl_Module
>> {
>> void *m_pRealHandle;
>> const char *m_pLastError;
>> };
>>
>> in osl/unx/module.c, malloc one of those and return *that* as the
>> oslModule from the osl_loadModule* family. Free it in osl_unloadModule.
>> Do the fixup in the various methods to cast oslModule to unx_impl_Module
>> and get the realhandle out of it for the dl* family. Now can add a new
>> toplevel osl c-function to check for error.
>>
>> oslModule stays a void* and all should remain abi-groovy methinks ?
>
> That is a clever hack, but API-wise I consider it so ugly that I'd rather
> prefer the extra osl_loadModuleWithError() variants than this.
I would prefer Caolán's solution. Given that dlopen-followed-by-dlerror is
broken (SUSv4 states "The dlerror() function need not be thread-safe."), I
would try to encapsulate that broken (but pragmatically necessary) sequence as
much as possible. (With the unx_impl_Module solution, one could even imagine
locking a mutex around dlopen/dlerror in osl_loadModule, so that at least all
non-third-party-calls to dlopen/dlerror cooperate for correct multi-threaded
behavior. But that would probably be overkill.)
-Stephan
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
