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

Mike Kestner mkestner at ximian.com
Fri Apr 6 11:31:35 EDT 2007


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#.  

glib_thread_init is only necessary if using glib from multiple threads.
I was under the impression the g_idle and g_timeout were exceptions to
this rule, and allowed context switching from non-gui to gui threads.
This works on linux just fine.  But it turns out from talking to Tor
that it's just a fluke.  The win32 port requires the g_thread_init call
in that scenario.

So I'm now thinking we need to add the GLib.Thread.Init call as you
suggested.  However, the Gdk.Threads.Init call should not really be
implicitly performed for every Gtk# application.  The burden of calling
that function should fall on the user, and only on users who really
really really really know what they are doing and want to do
multithreaded drawing.  Otherwise, it is unnecessary overhead for all
the programs that don't need it.

Lluis and I have recently discovered it is possible that Gtk# has been
inadvertently using glib from the GC thread via Dispose overrides.  I
have a patch in the works to fix this condition by doing our context
switch in the finalizer prior to calling Dispose.  It's possible this
has been contributing some instability on win32 as well, with more
aggressive/ differently timed garbage collection.

> 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.

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.

>   * Application.cs is already more than a thin "one-to-one" wrapper 
> around Gtk+ entry points.

Gtk# has never really been a one-to-one wrapper.  People have asked me
for a "thinner" wrapper in many areas in numerous cases and I have
resisted exposing internals that I think are better off pinvoked by
expert users.

>   * Gtk# applications seem to make more use of threads than C Gtk+ 
> applications.

Every Gtk# application uses threads, because of the GC thread
interactions.  I thought the g_timeout calls were exempt from the
restriction, but now I know otherwise.  It's on my list to fix next
week.
  
-- 
Mike Kestner <mkestner at ximian.com>



More information about the Gtk-sharp-list mailing list