Hi Mike, Alp. At 01:31 AM 7/04/2007, you wrote: >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.
As far as I know, being only a Windows user at this point, the issue only arises on certain Windows systems. What I'd like to know is what the actual issue is. If a non-threadsafe operation is being performed and just happens to work on most systems, all it takes is a change in architecture or in the Linux kernel for example to break the API on those other systems. From a purely chump user POV, I don't agree with the idea that it's my responsibility to use work-arounds to make an API stable on a not-uncommon target platform. I also can't imagine what amount of overhead could justify not ensuring this stability when problems are occuring with Gtk#'s own sample applications - what I'm saying is that if what I'm observing is in fact the norm, the problem is not limited to advanced uses of Gtk# or to systems that are particularly unusual. > > 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. Are you now saying you've changed your mind? And again I'd like to know more about what this overhead is - is this something I should be programmatically deciding to do or not do based on examination of the system I'm running on? Or is this something that can be fixed over time in GLib/Gdk themselves? Thanks in advance for any further info. Aaron. --------------------------------------------------------------------------------- Aaron Oxford - aaron+hardwarehookups .com .au Director, Innovative Computer Solutions (Aust) Pty. Ltd. 49 Maitland Rd, Mayfield, NSW 2304 Australia http://www.ic-solutions.com.au Developer, SourceForge project VioLet Composer http://sourceforge.net/projects/buzz-like _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
