[Libreoffice] Reporting an error when loading of a component fails

[Stephan Bergmann]

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