Re: Less locking in gtype.c



Hi Alex,

On Thu, 6 Sep 2001, Alex Larsson wrote:
> One possible way out would be to define GType to actually be gpointer,
> therefore giving warnings for broken code. This unfortunately does not
> work though, as you cannot switch on pointers.

	It seems I duplicated your work here :-) but mine is somewhat
unfinished as yet. I used a pointer type for GType - and everything looked
great except for the STATIC_SCOPE bits - where we break the opacity of the
GType and expose it as an integer. of some sort. Of course - we could
still whack this bit into the bottom bits of a pointer if we had some
'fun' macros used everywhere to set the STATIC_SCOPE flag on types - I
think it might still be well worth using a macro to set the static scope
flag and force people to use it by renaming the flag.

	As for switching - there was not overly much of this going on it
seems; there being only 4 switches total in gobject, none of them on types
:-) Either way, I tried to make this happy / the transition smooth by
having the 'old' integer stored inside the type structure.

> In the end, it will cause us some more 64bit breakage initially, but i
> think the performance gain is worth it.

	Given that the VFS forces us to have threading initialized in all
Gnome code - and that the current type system cannot remove a lock /
unlock on eg. a GTK_WIDGET () checked cast, the importance of the vast
improvement that this gives us in terms of the ability to propagate type
lifecycle invariants cannot be overestimated :-) but you knew that anyway.

	Great work,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot





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