Re: ActivationContext and shlib servers
- From: Michael Meeks <michael ximian com>
- To: Maciej Stachowiak <mjs eazel com>
- Cc: Dietmar Maurer <dietmar ximian com>, "gnome-components-list gnome org" <gnome-components-list gnome org>
- Subject: Re: ActivationContext and shlib servers
- Date: Sat, 27 Jan 2001 20:12:27 -0500 (EST)
On 27 Jan 2001, Maciej Stachowiak wrote:
> > Although; in fact with a helper function, if they type was
> > registered when you hit the query you could re-init the class data with
> > the class_init function thus solving any remaining problems. Of course if
> > you were doing very broken stuff you could still scupper yourself by
> > accessing a broken GtkType, but this seems unlikely.
>
> I don't think that will work. The GtkType contains pointers into your
> code besides the data created by the class_init function (for
> instance, a pointer to a class_init function which may well have been
> unloaded and then reloaded at a new location).
Well; fair enough, however assuming we arn't using the base class
initialization ( which few people use ), then I think we can dispense with
the delayed class_init function altogether - I propose:
GtkType
bonobo_type_unique (...)
{
GtkType old, new;
assert (info->instance_init == NULL);
if ((old = gtk_type_from_name (info->name)) {
Klass *new_class = g_malloc (info->class_size);
info->init_class (new_class);
For-old-and-all-children-recursively {
Klass = gtk_type_class (child_type);
memcpy (klass, new_class, info->class_size);
}
return old;
} else {
Tmpptr init_class = info->init_class;
Klass *new_class;
info->init_class = NULL;
new = gtk_type_unique (parent, info);
new_class = gtk_type_class (new);
init_class (new_class);
return new;
}
}
That gets rid of the need for the class_init function to be set,
and deals with the problem of stale children at the same time.
> > So, I still think we can work around this fairly easily.
>
> If you come up with a workaround you think works, I'd love to hear
> about it. Owen and Havoc both say it is impossible and I tend to trust
> them on Gtk+ matters.
Oh; well then, there is probably something silly in my above
proposal, but I can't see it right now. Clearly there is the problem of
people creating / using types with the same name from other places when
the shlib has been unloaded, but that sounds like broken code anyway.
Regards,
Michael.
--
mmeeks gnu org <><, Pseudo Engineer, itinerant idiot
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]