Re: Unloading providers (again)

On 10/24/2013 09:14 PM, Karl Schopmeyer wrote:> I wish you would come up
with some easy ones :-).  In any case I just
> went ahead and created a bug to we have a record
> of this.  Bug 9808.

I am not sure there is a real bug in Pegasus, the crash I described is
due to glib2 incapability to clean up after itself.

See https://bugzilla.gnome.org/show_bug.cgi?id=374940

<from the next email>
On 10/24/2013 09:28 PM, Karl Schopmeyer wrote:
> The only generic soluton I know is to destroy the thread pool first and
> dlclose() providers after that. Looking at ProviderAgent.cpp, it looks
> like lot of work since one ProviderAgent.cpp may handle multiple
> providers and they can be unloaded dynamically, not only at cimprovgt
> shutdown, right? (Note that OpenLMI uses only one provider per
> cimprovagt process so it might be a bit easier in our case).
> 
> 
> You are correct that the providers will be dynamically loaded and unloaded
> from the agent, just as they would be if the providers are unloaded from
> the server itself.
> 
> Is there a way to force the agent to get all the callbacks set at its
> startup
> and would that same instance of libglib2 be used by is dlopened providers?
> 
> If that were the case, then would not the cleanup callbacks be within the
> provagt threads, not the provider threads.

I don't think it is possible, the callbacks are initialized when glib2
first encounters the thread and needs thread local storage, i.e. when a
provider first calls specific glib2 functions. So, if cimproavt spawns a
new thread from whatever reason and this thread eventually calls glib2
(through the provider), the thread is 'tainted' and its destruction will
crash when glib2 is unloaded.

Anyway, it's clearly glib2 bug (or "well-known and documented
limitation", as they call it), I am just looking for a workaround in
Pegasus and I don't see an easy one. In the provider, we can prevent
glib2 from unloading on dlclose() of the provider, see
https://bugzilla.redhat.com/show_bug.cgi?id=1010238#c9

Jan