[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
aaron at hardwarehookups.com.au
Sat Apr 7 04:06:04 EDT 2007
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 Oxford - aaron+hardwarehookups .com .au
Director, Innovative Computer Solutions (Aust) Pty. Ltd.
49 Maitland Rd, Mayfield, NSW 2304 Australia
Developer, SourceForge project VioLet Composer
More information about the Gtk-sharp-list