[Gtk-sharp-list] ThreadNotify

[Vladimir Vukicevic]

On Thu, 2002-10-10 at 11:40, Miguel de Icaza wrote:
> > 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
> > e
> 
> The issue really is that we should not be queuing more data if there is
> already data queued in.  The reason is that it is a redundant task, and
> also because if you queue enough information (the system buffer size),
> you will block the calling application.
> 
> So what we need is a shared variable that says whether we should queue
> or not more data.  The side effect is that it will address the problem
> you see right now.

Hmm, will it?  If we start with the assumption that you should be using
a Queue to pass data back and forth between threads, then we're either
going to have to assume that one call of the notify handler is
equivalent to one call of NotifyMain(), in which case the GIO handler
will/should consume all available data from the pipe instead of just one
byte per invocation; or we're going to have to assume that you may have
a backlog of data for each call of the handler, and it's up to you in
your application to read as much from your private Queue as you want.

Perhaps these two could be combined in a ThreadNotifyQueue class, which
will give you one callback per notify semantics, with a piece of user
data from a queue, so that you don't have to worry about how the details
are implemented (i.e. it could just emit the event as many times as
there are items in the queue, up to some number, etc.)?

	- Vlad

-- 
Vladimir Vukicevic <vladimir@pobox.com>