Re: gdk_threads_init? (was Re: IMPORTANT: a big problem with gnome 2)



On Sun, 2001-10-21 at 14:39, Owen Taylor wrote:
> 
> Darin Adler <darin bentspoon com> writes:
> 
> > on 10/21/01 11:26 AM, jacob berkman at jacob ximian com wrote:
> > 
> > > however, i don't really understand the gnome program stuff (does
> > > anyone?), so there could be a better way of doing it there.  or,
> > > gnome-vfs could do its thread initialization stuff lazily - i don't know
> > > if this is realistic or not.
> > 
> > I think that gnome-vfs probably could do its thread initialization lazily.
> > But that still doesn't guarantee it will happen after gtk_init, does it?
> 
> While I don't think initializing GNOME really should initialize
> threading (~10% performance hit from glib and libc overhead)

so it seems that libgnome doesn't even make any gnome-vfs calls (aside
from gnome_vfs_init()).  is the dependency on gnome-vfs somewhere other
than the .c and configure.in files?

libgnomeui does make gnome-vfs calls, and, in gnome-vfs-util.c, async
ones.  however, it's only in one file.
 
> it might make sense to remove the automatic g_thread_init() =>
> GDK uses thread mutexes and force people to call gdk_threads_init()
> separately.
> 
>  - Pro: people not threading their GUI don't need to learn the
>    GDK thread rules. (With Bonobo and it's reentrancy fun/hell the
>    only way to get the thread rules right is to unlock GDK
>    around every CORBA call.)

(this is the gnome 1 behaviour if you initialize gnome-vfs after gtk)

>  - Con: People actually using GDK threading would start crashing
>    misbehaving until they figured out they needed to add 
>    gdk_threads_init().

if it's mentioned in the changes doc then this is ok...

jacob 
-- 



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