[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
alp at atoker.com
Fri Apr 6 04:10:30 EDT 2007
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
> 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
* Gtk# applications seem to make more use of threads than C Gtk+
More information about the Gtk-sharp-list