Re: ActivationContext and shlib servers



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]