Re: ActivationContext and shlib servers



Maciej Stachowiak wrote:

> Dietmar Maurer <dietmar ximian com> writes:
>
> 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.

I see.

> 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.

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.

> 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?

> 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 ;-)

Many thanks for your help,

 Dietmar





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]