зеркало из https://github.com/mono/mail-archives.git
130 строки
5.8 KiB
HTML
130 строки
5.8 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<TITLE> [Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
|
|
</TITLE>
|
|
<LINK REL="Index" HREF="index.html" >
|
|
<LINK REL="made" HREF="mailto:gtk-sharp-list%40lists.ximian.com?Subject=%5BGtk-sharp-list%5D%20Fwd%3A%20Re%3A%20%20Gtk%23%20instability%20nightmares&In-Reply-To=46160076.4000003%40atoker.com">
|
|
<META NAME="robots" CONTENT="index,nofollow">
|
|
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
|
|
<LINK REL="Previous" HREF="007957.html">
|
|
<LINK REL="Next" HREF="007962.html">
|
|
</HEAD>
|
|
<BODY BGCOLOR="#ffffff">
|
|
<H1>[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares</H1>
|
|
<B>Mike Kestner</B>
|
|
<A HREF="mailto:gtk-sharp-list%40lists.ximian.com?Subject=%5BGtk-sharp-list%5D%20Fwd%3A%20Re%3A%20%20Gtk%23%20instability%20nightmares&In-Reply-To=46160076.4000003%40atoker.com"
|
|
TITLE="[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares">mkestner at ximian.com
|
|
</A><BR>
|
|
<I>Fri Apr 6 11:31:35 EDT 2007</I>
|
|
<P><UL>
|
|
<LI>Previous message: <A HREF="007957.html">[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
|
|
</A></li>
|
|
<LI>Next message: <A HREF="007962.html">[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#7958">[ date ]</a>
|
|
<a href="thread.html#7958">[ thread ]</a>
|
|
<a href="subject.html#7958">[ subject ]</a>
|
|
<a href="author.html#7958">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
<HR>
|
|
<!--beginarticle-->
|
|
<PRE>On Fri, 2007-04-06 at 09:10 +0100, Alp Toker wrote:
|
|
|
|
><i> > Can I very strongly suggest that
|
|
</I>><i> >
|
|
</I>><i> > if(!GLib.Thread.Supported)
|
|
</I>><i> > GLib.Thread.Init();
|
|
</I>><i> > Gdk.Threads.Init();
|
|
</I>><i> >
|
|
</I>><i> > be placed inside Application.Init()? Basically the whole API is
|
|
</I>><i> > broken on a dual core system unless these calls are made. It's either
|
|
</I>><i> > this or you need to update every doco and sample in circulation to
|
|
</I>><i> > include these lines - something I'm guessing would be impractical. :-)
|
|
</I>
|
|
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.
|
|
|
|
><i> When I originally implemented the GLib.Thread class, I proposed that it
|
|
</I>><i> be used automatically in Application.Init(). Mike made the point that
|
|
</I>><i> Gtk# is a binding and that there's value in keeping a one-to-one mapping
|
|
</I>><i> of the original API to the C# API to ease porting between languages.
|
|
</I>><i> It'd be annoying to find out that Gtk# was doing magic behind the scenes
|
|
</I>><i> yet your identical c/pygtk/gtkmm port doesn't work.
|
|
</I>
|
|
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.
|
|
|
|
><i> * Application.cs is already more than a thin "one-to-one" wrapper
|
|
</I>><i> around Gtk+ entry points.
|
|
</I>
|
|
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.
|
|
|
|
><i> * Gtk# applications seem to make more use of threads than C Gtk+
|
|
</I>><i> applications.
|
|
</I>
|
|
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 <<A HREF="http://lists.ximian.com/mailman/listinfo/gtk-sharp-list">mkestner at ximian.com</A>>
|
|
|
|
</PRE>
|
|
|
|
|
|
|
|
|
|
<!--endarticle-->
|
|
<HR>
|
|
<P><UL>
|
|
<!--threads-->
|
|
<LI>Previous message: <A HREF="007957.html">[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
|
|
</A></li>
|
|
<LI>Next message: <A HREF="007962.html">[Gtk-sharp-list] Fwd: Re: Gtk# instability nightmares
|
|
</A></li>
|
|
<LI> <B>Messages sorted by:</B>
|
|
<a href="date.html#7958">[ date ]</a>
|
|
<a href="thread.html#7958">[ thread ]</a>
|
|
<a href="subject.html#7958">[ subject ]</a>
|
|
<a href="author.html#7958">[ author ]</a>
|
|
</LI>
|
|
</UL>
|
|
|
|
<hr>
|
|
<a href="http://lists.ximian.com/mailman/listinfo/gtk-sharp-list">More information about the Gtk-sharp-list
|
|
mailing list</a><br>
|
|
</body></html>
|