Re: Minutes of the GTK+ Team Meeting - 2009-11-27
On Wed, 2009-11-25 at 17:52 -0500, Matthias Clasen wrote: On Tue, Nov 24, 2009 at 5:13 PM, Emmanuele Bassi eba...@gmail.com wrote: = minutes for the 2009-11-27 meeting = Hey, thanks for sending these, and sorry for my nonattendance...my dentist had to go in deep :-( 6. Rename configure.in to configure.ac [Enselic] - trivial issue - mclasen will have to decide - ebassi points out that GLib should switch as well - kalikiana wants to know if there are compatibility issues for the rename - none direct; there might be external scripts relying on configure.in I don't have any problem with doing this, even if I don't see much benefit. Just do it for all I care, but please make sure that make distcheck still works. What about using AM_SILENT_RULES? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2009-11-27
On Thu, 2009-11-26 at 12:47 +0100, Alexander Larsson wrote: I don't have any problem with doing this, even if I don't see much benefit. Just do it for all I care, but please make sure that make distcheck still works. What about using AM_SILENT_RULES? should already be working, but it's turned off by default. ciao, Emmanuele. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2009-11-27
On Thu, 2009-11-26 at 12:09 +, Emmanuele Bassi wrote: On Thu, 2009-11-26 at 12:47 +0100, Alexander Larsson wrote: I don't have any problem with doing this, even if I don't see much benefit. Just do it for all I care, but please make sure that make distcheck still works. What about using AM_SILENT_RULES? should already be working, but it's turned off by default. Sweet /me wires make V=0 into hands ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Proposal: Enable threads by default
This was previously discussed here, but was sort of hidden in a technical discussion so it got no replies. I'm starting over in order to reach a wider target for the discussion. I'll start with the proposal and then explain the reasons for it: Starting with next glib release: * libgobject links to libgthread * g_type_init() starts with: #ifdef G_THREADS_ENABLED if (g_thread_supported()) g_thread_init (NULL); #endif This means that everything above gobject can rely on thread primitives being availible, and that global stuff in glib (mainloop, gslice, globals, etc) are threadsafe. It also means that simple apps that just use the datatypes and utilities in glib (and don't use gobject) won't require threads. Note however, that this doesn't mean that GDK/GTK are threadsafe by default. That is an additional thing, and it can't even be enabled by default because it requires changes in non-threadsafe applications. So, apps still need to call gdk_threads_init(). It also allows applications to call g_thread_init() before g_type_init() in order to specify custom threading primitives. So, what is the reason for this? The current system (apps have to call g_threads_init() before any other glib functions) works for applications that need to use threads. However, it breaks down when libraries or plugins need to use threads. Since its not allowed to call g_thread_init() late these libraries can't use threads at all unless the application initialized them, which many don't. Additionally, and part of the problem, is that current glib allows late initialization, or at least it doesn't crash in flames if you do so. However, there is no guarantee that this doesn't break in weird ways as a lot of threadsafe code doesn't correctly handle late thread initialization (including libgio, see bug 595757). In fact, outside of libglib its not really possible to sanely handle it. ORBit2 (and thus gconf which uses it) initializes threads late, so in practice most applications actually initialize threads, but in a broken and risky way. Historically we've avoided threads a lot because the cost of just having basic thread-safety was to high. But, with the current situation (futexes/NPTL/g_slice) things have improved a lot on the software side, so the costs are not as bad anymore. And threads are starting to become more important these days too, with multi-core processors and gio using threads for async local i/o. So, while I personally still recommend people to not use threads unless they have a very good reason, I think that we are now at a place where its used widely enough and is important enough that we need to be able to rely on the basic threading primitives in our libraries and plugins by default. It would be nice to be able to drop the whole thread initialization issue for Gnome 3.0. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
Alexander Larsson alexl at redhat.com writes: Starting with next glib release: * libgobject links to libgthread * g_type_init() starts with: #ifdef G_THREADS_ENABLED if (g_thread_supported()) g_thread_init (NULL); #endif Finally. I'm so sick of the issues (mostly performance-related) that crop up due to threading/no threading/late threading in all the various applications, that I'm really happy to see this happen. One less vector hard-to-trigger bugs can creep into the code. Benjamin ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Minutes of the GTK+ Team Meeting - 2009-11-27
On 11/26/2009 07:11 AM, Alexander Larsson wrote: On Thu, 2009-11-26 at 12:09 +, Emmanuele Bassi wrote: On Thu, 2009-11-26 at 12:47 +0100, Alexander Larsson wrote: I don't have any problem with doing this, even if I don't see much benefit. Just do it for all I care, but please make sure that make distcheck still works. What about using AM_SILENT_RULES? should already be working, but it's turned off by default. Sweet /me wires make V=0 into hands export V=0 ? ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
Am Thu, 26 Nov 2009 14:35:36 +0100 schrieb Alexander Larsson al...@redhat.com: This was previously discussed here, but was sort of hidden in a technical discussion so it got no replies. I'm starting over in order to reach a wider target for the discussion. I'll start with the proposal and then explain the reasons for it: Starting with next glib release: * libgobject links to libgthread * g_type_init() starts with: #ifdef G_THREADS_ENABLED if (g_thread_supported()) g_thread_init (NULL); #endif You mean this: if (!g_thread_supported ()) g_thread_init (NULL); Just to prevent confusion. Since the above snippet wouldn't work. :) ciao, Christian ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Proposal: Enable threads by default
On Thu, 2009-11-26 at 14:35 +0100, Alexander Larsson wrote: Starting with next glib release: * libgobject links to libgthread * g_type_init() starts with: #ifdef G_THREADS_ENABLED if ([!]g_thread_supported()) g_thread_init (NULL); #endif This means that everything above gobject can rely on thread primitives being availible, and that global stuff in glib (mainloop, gslice, globals, etc) are threadsafe. Yes, please! Cheers -Tim ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
