Re: ActivationContext and shlib servers

[Maciej Stachowiak <mjs eazel com>]

Dietmar Maurer <dietmar ximian com> writes:

> 
> > I actually suspect the current behavior may be intentional (shlib
> > servers are sort of implicitly factories), but only Elliot knows for
> > sure. It appears to be the same as the goad behavior from what I can
> > tell.
> >
> > Can you please explain to me why you need this behavior, and if you
> > are still convinced the current behavior is wrong.
> 
> We have a new object tracking system in bonobo, which counts the
> objects activated from within a shared library. This enables us to
> unload the shared library if all objects (in the library) are
> deactivated.
> The code assumes that oaf only activates necessary factories. To activate
> 
> a new factory every time is simply useless (I can see no reason
> to do that).
> 
> I see two solutions:
> 
> 1.) oaf_active_server_register would have to register shlib servers
> in a table inside the process instead of talking to oafd
> 
> 2.) I can change the bonobo code to deal with multiple factories.
> 
> I would prefer solution 1.
> 

1.) There's no need to use factories with shlib servers. Because a new
  object is instantiated each time, you effectively get factory
  semantics already.

2.) OAF already supports automatic unloading of shlib servers, using
  oaf_plugin_use and oaf_plugin_unuse. oaf_plugin_unuse was buggy
  until recently and would reliably crash your app but I have just now
  committed a fix. nautilus/components/tree/libmain.c is an example of
  how to do it properly, only the oaf_plugin_unuse call is #ifdef'd
  out due to point 3.

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.

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.

Hope this helps. Let me know if there is anything else I can do to to
help you.

 - Maciej