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

[Alp Toker]

Mike Kestner wrote:
> 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#.  

This isn't only an issue on Win32, it's an issue on any runtime that 
isn't Mono.

 From mini_init() in mono/mono/mini.c:

	if (!g_thread_supported ())
		g_thread_init (NULL);

I consider this a bug of the Mono runtime, but at least if we had put it 
in Application.Init(), it would have levelled the playing ground between 
.NET runtimes. Like I said before, the sad thing is that people write 
applications that would otherwise be perfectly portable except for their 
reliance on this behaviour.

Sometimes it's worth sticking to principles but I've never been 
convinced that expecting Gtk# developers to understand this quirk is a 
good move, especially now as their applications are bound to break 
anyway as Mono moves towards eglib.

I also think that representing this as a performance issue is not 
entirely honest when the Mono runtime itself does g_thread_init() for 
_every_ application. Not being able to communicate this issue and a few 
  others to Mike resulted in my (slightly misguided) "NGtk" Gtk# 
development branch for those who still remember.