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

[Mike Kestner]

On Sat, 2007-04-07 at 18:06 +1000, Aaron Oxford wrote:

>  From a purely chump user POV, I don't agree with the idea that it's 
> my responsibility to use work-arounds to make an API stable on a 
> not-uncommon target platform. I also can't imagine what amount of 
> overhead could justify not ensuring this stability when problems are 
> occuring with Gtk#'s own sample applications - what I'm saying is 
> that if what I'm observing is in fact the norm, the problem is not 
> limited to advanced uses of Gtk# or to systems that are particularly unusual.

I'm not sure why we're still having this discussion since I thought my
last message stated that I plan to add a fix for the glib thread init
issue next week.  

FWIW, I never meant to imply that workarounds should be added to user
code instead of Gtk#.  What I meant was that I would rather fix root
causes in Gtk# (or its upstream bound libraries), instead of committing
things that just seem to fix the problem even though we have no clear
understanding of why they fix the problem, or what problem they are
actually fixing.  Until recently, that was where the Thread.Init
"workaround" sat in my mind.  Now that I understand why it fixes the
problem on win32, why that problem is not a bug in the Gtk+ win32 port,
and why the problem doesn't exist on mono on linux, it's clear that Gtk#
should be doing that initialization.

> >I don't recall that discussion.  My recollection was being opposed to
> >the overhead of performing that initialization indiscriminately for
> >applications that did not intend to use it.
> 
> Are you now saying you've changed your mind?

I believe that based on its own usage of multithreading with glib, Gtk#
needs to call g_thread_init prior to any other glib calls.  That's not
exactly changing my mind in the context of the quoted discussion, but I
think that's what you are asking.

-- 
Mike Kestner <mkestner at ximian.com>