Il giorno lun, 05/07/2010 alle 18.55 +0800, Jason Heeris ha scritto:
> On 5 July 2010 18:32, Pietro Battiston <m...@pietrobattiston.it> wrote:
> > You wouldn't need threading if you could do:
>
> > def do_processing(self):
> > if self.counter < 1000:
> > import time
> > time.sleep(.01)
> > return True
> > self.counter += 1
> > self.emit('processing-done')
>
> Well... this in itself wouldn't work, since anything after the
> "return" would be skipped.
Uhm sure.
> But I hadn't thought of this before — you
> could make this into a generator (replace "return" with "yield"), and
> somehow wrap it in a "for" loop that did what idle_add expects. But
> now we're getting kind of close to rolling our own threading
> implementation, which seems a bit hacky.
Personally, I find that when the lenghty operation can be fragmented in
small enough parts, this is not hacky, this is perfectly natural (much
more than having threads or even other event loops misteriously flowing
around).
When the operation _can't_ be fragmented, again it's not hacky, it's
just impossible.
If you want an example, my "gvb" app, which you can find in
Debian/Ubuntu, doesn't use threading at all (and multiprocess neither).
That's a problem in the initializations, which take a lot of time and
block the UI, but for drawing a frame at a time it's perfect - and
notice "frames" of the simulation _don't necessarily correspond_ to
frames rendered to screen.
Pietro
_______________________________________________
pygtk mailing list pygtk@daa.com.au
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
