On Mon, Mar 03, 2003 at 08:38:22AM -0600, Jon Nelson wrote:
> On Mon, 3 Mar 2003, Jon Nelson wrote:
>
> > On Fri, 28 Feb 2003, Christian Reis wrote:
> >
> > > On Fri, Feb 28, 2003 at 08:56:04AM -0600, Jon Nelson wrote:
> > > > To make progress bars work, I use the following code:
> > > >
> > > > while gtk.events_pending():
> > > > gtk.mainiteration(0)
> > > >
> > > > And here is where I get into trouble.
> > > >
> > > > Assume the FIFO is still readable (perhaps I haven't read all of the
> > > > data, or perhaps new data has arrived).
> > > >
> > > > It appears that gtk.mainiteration will call read_from_fifo *again*,
> > > > which calls handle_fifo, which may result in calling mainiteration,
> > > > which may result in read_from_fifo being called, which ....
> > >
> > > Why not just use a global variable to lock this? Something like
> > >
> > > self.block_read = 1
> > >
> > > and then set this just before your mainiteration loop. Then check for it
> > > inside read_from_fifo and only perform the actual read if you aren't
> > > blocked.
> >
> > I tried that very approach, and it didn't work for me. I didn't spend a
> > great deal of time trying to figure out why. I'll look into it.
>
> Tried it. Doesn't work. Here's why.
>
> Assume code similar to this:
>
> def read_from_fifo(self, file, condition):
> self.log("in read_from_fifo - %s" % (str((file,condition))))
> if self.block_read:
> return file
> ...
> self.io_queue.put( (verb, args) )
> self.block_read = 1
> self.handle_fifo_here()
> self.block_read = 0
> return file
Why do you need to return file? This doesn't look very safe -- isn't
file created inside GTK+ and passed in to the callback? (I can't remember
how input_add works, darn.)
Take care,
--
Christian Reis, Senior Engineer, Async Open Source, Brazil.
http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
_______________________________________________
pygtk mailing list [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
