[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
alp at atoker.com
Sat Apr 7 14:43:23 EDT 2007
Mike Kestner wrote:
> On Fri, 2007-04-06 at 09:10 +0100, Alp Toker wrote:
>>> 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. :-)
> 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
From mini_init() in mono/mono/mini.c:
if (!g_thread_supported ())
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.
More information about the Gtk-sharp-list