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/