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

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