Aaron Oxford wrote: > Hi Adam and list, > > Thanks for the heads-up. From reading about those Init() functions in > the docs it seems GLib(#?) and Gdk(#?) have some critical sections > that are not handled properly by default. > > Now to get on my high-horse for a bit, this is a major no-no even on > single core systems, and the speed with which it broke my dual core > system suggests that these are *serious* misimplementations from a > threading point of view. Minor problems like this can take days or > weeks to manifest; these problems take the app down within a matter of > seconds. > > 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. :-)
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. This would all have been fine, but it turned out that Gtk+ is more forgiving on Unix than it is on Windows, so Gtk# applications get written, released and only when someone tries to run them on Windows is it found that they're unstable. Hopefully they'll notice the warning in the API documentation and add the check-and-init to their application's startup, and everything will just work. This issue has been known for 5 years, so it's probably not going to change any time soon. There are however still some arguments in favour of updating Application.Init(): * Application.cs is already more than a thin "one-to-one" wrapper around Gtk+ entry points. * The scenario where a Gtk# application is built and deployed by a developer who only has access to Linux but is then run by Windows users is quite common. This is different to C applications where some developer will have to explicitly build on Windows, noticing the bug in the process. * Gtk# applications seem to make more use of threads than C Gtk+ applications. _______________________________________________ Gtk-sharp-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
