On Fri, 2007-04-06 at 09:10 +0100, Alp Toker wrote: > > Can I very strongly suggest that > > > > if(!GLib.Thread.Supported) > > GLib.Thread.Init(); > > Gdk.Threads.Init(); > > > > be placed inside Application.Init()? Basically the whole API is > > broken on a dual core system unless these calls are made. It's either > > this or you need to update every doco and sample in circulation to > > include these lines - something I'm guessing would be impractical. :-)
AFAICT, this is only an issue on win32, correct? I have not heard reports of any instability on linux that this "workaround" fixes. I had considered in the past adding such a check with platform specific guarding around it for win32, but have resisted doing that because it felt like a workaround if added to Gtk#. glib_thread_init is only necessary if using glib from multiple threads. I was under the impression the g_idle and g_timeout were exceptions to this rule, and allowed context switching from non-gui to gui threads. This works on linux just fine. But it turns out from talking to Tor that it's just a fluke. The win32 port requires the g_thread_init call in that scenario. So I'm now thinking we need to add the GLib.Thread.Init call as you suggested. However, the Gdk.Threads.Init call should not really be implicitly performed for every Gtk# application. The burden of calling that function should fall on the user, and only on users who really really really really know what they are doing and want to do multithreaded drawing. Otherwise, it is unnecessary overhead for all the programs that don't need it. Lluis and I have recently discovered it is possible that Gtk# has been inadvertently using glib from the GC thread via Dispose overrides. I have a patch in the works to fix this condition by doing our context switch in the finalizer prior to calling Dispose. It's possible this has been contributing some instability on win32 as well, with more aggressive/ differently timed garbage collection. > When I originally implemented the GLib.Thread class, I proposed that it > be used automatically in Application.Init(). Mike made the point that > Gtk# is a binding and that there's value in keeping a one-to-one mapping > of the original API to the C# API to ease porting between languages. > It'd be annoying to find out that Gtk# was doing magic behind the scenes > yet your identical c/pygtk/gtkmm port doesn't work. I don't recall that discussion. My recollection was being opposed to the overhead of performing that initialization indiscriminately for applications that did not intend to use it. > * Application.cs is already more than a thin "one-to-one" wrapper > around Gtk+ entry points. Gtk# has never really been a one-to-one wrapper. People have asked me for a "thinner" wrapper in many areas in numerous cases and I have resisted exposing internals that I think are better off pinvoked by expert users. > * Gtk# applications seem to make more use of threads than C Gtk+ > applications. Every Gtk# application uses threads, because of the GC thread interactions. I thought the g_timeout calls were exempt from the restriction, but now I know otherwise. It's on my list to fix next week. -- Mike Kestner <[EMAIL PROTECTED]> _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
