On Wed, 12 Mar 2003, John K Luebs wrote:

> On Tue, Mar 11, 2003 at 09:15:06AM -0600, Jon Nelson wrote:
> > Did anybody come up with anything better than this?
> >
> > In the callback which was used in input_add:
> >
> >     old = gtk.events_pending
> >     def duh(*args):
> >       return 0
> >     gtk.events_pending = duh
> >     self.do_real_work_with_data_read_from_file(data_read_from_file)
> >     gtk.events_pending = old
> >
> > for this problem?
> >
> > The reason this appears necessary is explained below.
> > *Somebody* has a better solution, I'm sure of it!
>
> This seems really silly.
> If you're gonna f up events_pending in this way, then that means you are
> not going to ever pump the gtk event queue. If you really don't need to
> call mainiteration, then why don't you just remove the whole
> while gtk.events_pending(): gtk.mainiteration nonsense.

Actually, it means that gtk.events_pending() will always return 0 while
the function self.do_real_work_with_data_read_from_file is being run.

> Now the problem that you are running into is that select()/poll() and
> the glib FD polling mechanism are all level sensitive. When you
> input_add your fd, you are going to be notified whenever a read will not
> block. This means that if the OS had buffered 200 bytes, you were
> notified and only read 100 bytes, you will get the event again. Realize,
> that this is basically a good design, don't fight it.

I am quite aware of how select looping works.  If you had read the whole
thread (which it's clear you haven't) you would know that there is a
fundamental problem with timeout, I/O, and idle event functions -- they
can't do this:

while events.pending():
  gtk.mainiteration()

And the reason is that timeout, I/O, and idle events will get called,
again, in the nested mainiteration (if appropriate).  Additionally,
using the gtk I/O monitoring functions to remove the callback *in* the
callback doesn't appear to work, because it's entirely possible that
data arrives for the file *after* the read operation.

> The simplest thing for you to do is call gtk.input_remove or
> gobject.source_remove on your file descriptor/callback (the source_id is
> returned by input input_add/io_add_watch) sometime before you drain the
> event queue.

Tried that, didn't work.  It's in the thread somewhere.

--
"Never try to write to ROM - it wastes your time and annoys the ROM."

Jon Nelson <[EMAIL PROTECTED]>
C and Python Code Gardener
_______________________________________________
pygtk mailing list   [EMAIL PROTECTED]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/

Reply via email to