[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares

[Alp Toker]

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.