[Gtk-sharp-list] ThreadNotify

[Vladimir Vukicevic]

There seems to be a bug here, as exposed by tetsuo's sample program.

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.

The problem is that it's buffered. :)  This means that if your thread is
fast enough, it's going to call WakeupMain() N times before g_io learns
that data is available. Once it does, g_io is going make one callback,
and the user function in ThreadNotify only consumes 1 byte -- leaving
the rest in the buffer.  Thus gio is either going to call the function
again before a thread context switch happens, or there's going to be a
ton of calls at the end of whatever processing the thread is doing
that's making it emit these signals -- both cases will result in the
same data being reused multiple times.

One way to fix this is to make sure that when you're passing data to use
a Queue or some other form of data structure which will ensure you get
each bit of data only once.  This however makes it impossible to run the
gtk thread and the "worker" thread in lock-step (and it might be
prohibitively expensive to make a copy of the data, etc., etc).

So, would setting the buffer size on the pipe to 1 fix this?  Or do we
need a more elegant solution to ThreadNotify?

	- Vlad


-- 
Vladimir Vukicevic <vladimir@pobox.com>