Re: ActivationContext and shlib servers

[Maciej Stachowiak <mjs eazel com>]

Dietmar Maurer <dietmar ximian com> writes:

> 
> Yes, and we use oaf_plugin_unuse, but that is not the problem. The problem
> is that someone creates many server within a shlib. So you need to
> track each server created from anywhere within the shlib. You can  only
> unload the shlib if all those servers are destroyed.
> 

oaf_plugin_use/oaf_plugin_unuse provide reference counting
semantics. You oaf_plugin_use each time you create an object and
oaf_plugin_unuse each time you destroy one. There is no need to do any
extra tracking. Like I said, it works fine for the Nautilus tree view
modulo the Gtk itssue mentioned below.

> > 3.) Gtk+ 1.2.x does not allow safely unloading and reloading a shared
> >   object that defines a GtkType. The reason is that the old GtkType
> >   cannot be unregistered, so you can't create a new GtkType with the
> >   same name. However, the old GtkType points to memory in the old
> >   instance of the shared library rather than the new one, and there is
> >   no way to change the existing GtkType. The bottom line is that if
> >   your shared library component defines any Gtk classes, you can't
> >   safely unload it. If you use only predefined Gtk classes and plain
> >   structs for anything extra, though, it should be safe and work
> >   properly to unload.
> 
> Bad news - so we have to disable it for now. But it should be
> possible in the future?
> 

It will be doable with gobject in glib 2.0, according to Havoc and Owen.

> > 4.) Is there a reason you have to want to change the semantics of
> >   shlib servers relative to what oaf and goad have always done besides
> >   the shlib unloading? Because I think the unloading problem is
> >   solved. But if you need to address other problems as well, we can
> >   still consider making this change.
> >
> > 5.) I think you recently put in a warning about multiple factories in
> >   a library into Bonobo, due to misunderstanding how shlib components
> >   are supposed to work. I suggest you remove the warning and change
> >   the shlib components in question to not use a factory. libmain.c in
> >   nautilus/components/tree is again a fine example of how to do it
> >   right.
> 
> I have to rethink this point, give me some time ;-)

OK, no problem.

> Many thanks for your help,
> 

You're welcome, and I'll be glad to provide any further assistance you
need on activation related issues.

Regards,

Maciej