[Gtk-sharp-list] ThreadNotify: The saga continues
Pablo Baena
pbaena@uol.com.ar
24 Oct 2002 10:01:29 +0000
--=-Pik6N6M5I6wRG403nS17
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Hello!
I've been using Gtk# for a while now, got the usual stumbling blocks but
ultimately everything fits together. However, I have come to realize
something that I think is annoying from the point of view of a user.
That is, ThreadNotify. I've used it for a while and it served its
purpose very well for some time. When my small project got a little
bigger and I made a little heavier use of threads for the different
tasks, my code just started to became uglier and uglier, and just
because I had to use ThreadNotify everytime I needed to make the
smallest change to the widgets.
I was wondering if there is a plan to make the libraries thread safe,
not in the sense of insert mutexes for everything in Gtk (something I
think is the responsability of the user), but to allow getting the job
done without ThreadNotify.
So far, this is the only issue that I have encountered when dealing with
Gtk# programming for which I haven't found a workaround, and I think is
the only one that will annoy the most to the people starting to use it.
Just something I think should be in the wishlist.
Pablo
On Thu, 2002-10-10 at 11:08, Michael Meeks wrote:
Hi Vlad,
On Thu, 2002-10-10 at 07:27, Vladimir Vukicevic wrote:
> Basically, in ThreadNotify, when a thread is to be "notified", a byte is
> written to a fd. There's a GIO event waiting for data to be available
> on that pipe,and when there is, the byte is consumed, and the user
> callback is called.
I don't quite understand what the problem is, beyond the fact that the
threads are de-coupled. Ultimately (surely) - depending on how long the
processing code is that handles the event in the main-thread, many
events can pile up being pushed from the other thread.
If you want to block the other thread while waiting for the main-loop
to process the request; then I assume you want a different sort of
locking primitive. Surely making all notifications block the notifier is
not a good model ;-)
Ultimately surely, in any threaded world - notifications should contain
either no state, or sufficient state for the listener to act; since
subsequent fetches of state from the object may result in odd effects
(?).
Confuseldly,
Michael.
--
mmeeks@gnu.org <><, Pseudo Engineer, itinerant idiot
_______________________________________________
Gtk-sharp-list maillist - Gtk-sharp-list@ximian.com
http://lists.ximian.com/mailman/listinfo/gtk-sharp-list
--=-Pik6N6M5I6wRG403nS17
Content-Type: text/html; charset=utf-8
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/1.0.4">
</HEAD>
<BODY>
Hello!
<BR>
<BR>
I've been using Gtk# for a while now, got the usual stumbling blocks but ultimately everything fits together. However, I have come to realize something that I think is annoying from the point of view of a user. That is, ThreadNotify. I've used it for a while and it served its purpose very well for some time. When my small project got a little bigger and I made a little heavier use of threads for the different tasks, my code just started to became uglier and uglier, and just because I had to use ThreadNotify everytime I needed to make the smallest change to the widgets.
<BR>
<BR>
I was wondering if there is a plan to make the libraries thread safe, not in the sense of insert mutexes for everything in Gtk (something I think is the responsability of the user), but to allow getting the job done without ThreadNotify.
<BR>
<BR>
So far, this is the only issue that I have encountered when dealing with Gtk# programming for which I haven't found a workaround, and I think is the only one that will annoy the most to the people starting to use it. Just something I think should be in the wishlist.
<BR>
<BR>
Pablo
<BR>
<BR>
<BR>
On Thu, 2002-10-10 at 11:08, Michael Meeks wrote:
<BLOCKQUOTE>
<PRE><FONT COLOR="#737373"><FONT SIZE="3"><I>Hi Vlad,</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>On Thu, 2002-10-10 at 07:27, Vladimir Vukicevic wrote:</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> Basically, in ThreadNotify, when a thread is to be "notified", a byte is</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> written to a fd. There's a GIO event waiting for data to be available</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> on that pipe,and when there is, the byte is consumed, and the user</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>> callback is called.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I> I don't quite understand what the problem is, beyond the fact that the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>threads are de-coupled. Ultimately (surely) - depending on how long the</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>processing code is that handles the event in the main-thread, many</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>events can pile up being pushed from the other thread.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I> If you want to block the other thread while waiting for the main-loop</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>to process the request; then I assume you want a different sort of</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>locking primitive. Surely making all notifications block the notifier is</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>not a good model ;-)</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I> Ultimately surely, in any threaded world - notifications should contain</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>either no state, or sufficient state for the listener to act; since</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>subsequent fetches of state from the object may result in odd effects</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>(?).</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I> Confuseldly,</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I> Michael.</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>-- </FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I> mmeeks@gnu.org <><, Pseudo Engineer, itinerant idiot</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I></FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>_______________________________________________</FONT></FONT></I>
<FONT COLOR="#737373"><FONT SIZE="3"><I>Gtk-sharp-list maillist - Gtk-sharp-list@ximian.com</FONT></FONT></I></PRE>
</BLOCKQUOTE>
<A HREF="http://lists.ximian.com/mailman/listinfo/gtk-sharp-list"><FONT SIZE="3"><I>http://lists.ximian.com/mailman/listinfo/gtk-sharp-list</FONT></I></A>
<BLOCKQUOTE>
<PRE></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-Pik6N6M5I6wRG403nS17--