Tim Janik wrote: >> Again, this feels more like an after thought and not really the ideal >> solution here. > > well, at this point there is no compelling reason for a gtk program to not > enable threading i think. especially since recent file chooser backends > have been reported to dmand-init threading anway (which is clearly > *always* too late). > so fallback initialization of threading in gtk_init() and friends sounds > like a non-intrusive change that gets rid of the problem for a lot of > affected non-gnome apps. > do you have any concrete reason to object this?
I do agree that there is no compelling reason for a gtk+ program to not enable threading though - that seems perfectly fine. However, I would rather only call g_thread_init() for special implementations and have glib initialise it for me if I don't call it first. This seems more logical to me and also means that it is up to us when we call g_thread_init(). >> I think the question that needs answering first is: >> >> What in glib requires g_thread_init() to be called first? >> >> With my relatively limited experience of glib, all I can think of is: >> >> - gasyncqueue >> - gmain >> - gthread >> - gthreadpool >> - gslice >> - gtimer > > off-head, there's are also threading initializers in glog and gmem.c. > > i don't think this is a question properly phrased/answered though. > nothing in glib *needs* threading per se, except for dedicated > threading APIs (e.g. conditions, or async pools). > the question is whether all the threading aware code (which spreads > throughout all of glib, to make it thread-safe in general) can cope > with *late* g_thread_init() calls, and development has never focussed > on that. (we intentionally avoided that by demanding early calls to > g_thread_init if it is called at all.) And even now I think that is a good way of doing it. If we stick to this, I think having the g_thread_init() in gtk+ actually is a good idea. I think you either do that or have an initialisation function which allows the programmer to choose when calling _init() to enable threading or not (which should mean late thread initialisation would no longer be an issue). >> then perhaps a g_init() >> function is needed which we expect users to call first (like gtk_init()) > > GLib has so far supported the philosophy of not requirering an explicit > initialization call. mostly due to requests by Owen and a few others. Is there any reason not to do this? I mean, I remember when I first started writing applications and it seems strange that glib didn't follow suite with gtk+, gnomevfs, etc. Also with talks of gnomevfs moving closer to glib, would you need an initialisation function ay some point anyway? The only other similar base library implementation I have used was in my last job and we did have an _init() function and you could specify a bunch of options, one of which was to enable threading (by default it was disabled). If this approach was taken, then gtk+ could still call g_init() with some variable to enable threading. >> I would probably vote for initialising on demand. > > that'd have been ok for me as well, libgobject also requires that. > but it's simply too late to demand that at this point, such source+ABI > incompatible requirements can be introduced with 3.0 earliest. Having a g_init() function is a much cleaner and more non-intrusive method of doing this. It makes more sense to me actually, I think you know (from a programmers point of view) if you are going to have threading enabled and that decision is best made as early as possible is it not? Would you ever want to call g_thread_init() late in a program's execution? -- Regards, Martyn _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list