Hi, On Fri, Aug 15, 2008 at 5:55 PM, Brian J. Tarricone <[EMAIL PROTECTED]> wrote: > This breaks for libraries that require locking in threaded programs but > (obviously) not in non-threaded programs. You can get into a situation > where you call a lock() without threads initialised, then something > somewhere (whether in glib or a 3rd party lib) goes and calls > g_threads_init() because it thinks it needs it (even if it doesn't, because > the program isn't threaded), and then you call unlock(), and it breaks. > This is the example tml brought up with GtkHtml. >
AIUI with gthread, in effect we have an init function with an argument (threads_are_noop=true|false or more generally "set thread vtable") and all libs must agree on this argument. It's global state set up at init time. In this design, setting the argument isn't allowed in libraries, only in the app itself. Libraries run 'too late' to decide, they don't know what other modules may have run. Only the app can ensure it decides at the start of main(). Implication: libraries can't require threads, they have to work with or without depending on what the app does. Or they have to require that apps using the library specifically know the library will be used, and init threads in order to use the lib. If this is a problem (it kind of is) I'd argue that this global setting is just a broken idea. Possible solutions could be: * make the setting per-library/per-module instead of global so everyone can set it themselves * remove the setting; threads are always enabled * set a policy that only the app sets the setting, and libs/modules must conform * set a policy that the thread-requiring library can't be used in dlopen'd modules or otherwise when the app isn't expecting it, and the app must init threads But anyway, the bottom line is that args to init functions are in effect global variables set by multiple people in undefined order, unless you declare by policy who will set them... For gthread surely the easiest is to just always init threads inside g_mutex_new or the like. Havoc _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list