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

[Aaron Oxford]

Hi Mike, Alp.

At 01:31 AM 7/04/2007, you wrote:
>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.

As far as I know, being only a Windows user at this point, the issue 
only arises on certain Windows systems. What I'd like to know is what 
the actual issue is. If a non-threadsafe operation is being performed 
and just happens to work on most systems, all it takes is a change in 
architecture or in the Linux kernel for example to break the API on 
those other systems.

 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.

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

Are you now saying you've changed your mind? And again I'd like to 
know more about what this overhead is - is this something I should be 
programmatically deciding to do or not do based on examination of the 
system I'm running on? Or is this something that can be fixed over 
time in GLib/Gdk themselves?

Thanks in advance for any further info.

Aaron.
---------------------------------------------------------------------------------
Aaron Oxford   -   aaron+hardwarehookups .com .au
Director, Innovative Computer Solutions (Aust) Pty. Ltd.
49 Maitland Rd, Mayfield, NSW 2304 Australia
http://www.ic-solutions.com.au
Developer, SourceForge project VioLet Composer
http://sourceforge.net/projects/buzz-like