Re: ActivationContext and shlib servers
- From: Dietmar Maurer <dietmar ximian com>
- To: Maciej Stachowiak <mjs eazel com>, Michael Meeks <michael ximian com>
- Cc: "gnome-components-list gnome org" <gnome-components-list gnome org>
- Subject: Re: ActivationContext and shlib servers
- Date: Sat, 27 Jan 2001 09:23:14 +0100
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]