On 17.04.2010 10:55, Adrian Buehlmann wrote: > On 17.04.2010 04:00, Yuki KODAMA wrote: >> On Sat, Apr 17, 2010 at 07:10, Adrian Buehlmann <adr...@cadifra.com> wrote: >>> On 16.04.2010 23:58, Adrian Buehlmann wrote: >>>> On 16.04.2010 23:32, Adrian Buehlmann wrote: >>>>> Slightly off topic, but Herb Sutter (C++ standard and concurrent >>>>> programming guru) has a very nice blog entry about concurrent programming: >>>>> >>>>> Effective Concurrency: Prefer Futures to Baked-In “Async APIs” >>>>> >>>>> http://herbsutter.com/2010/01/17/effective-concurrency-prefer-futures-to-baked-in-async-apis/ >>>>> >>>>> A couple of programming libraries and languages have already used that >>>>> "future" design pattern (Java, upcoming C++0x thread library). >>>>> >>>>> Would be nice to find something like a "future" in PyQt as well (if >>>>> anyone has a pointer, please post!). >>>> >>>> Ah! It's there in Qt: http://doc.trolltech.com/4.6/qfuture.html >>>> >>>> Hmm. I can't seem to find it in the PyQt reference doc: >>>> http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/classes.html >>> >>> "The QtConcurrent namespace and the QFuture* classes related to it >>> appear to be missing" >>> >>> http://www.mail-archive.com/p...@riverbankcomputing.com/msg13749.html >>> >>> :-/ >> >> Thanks for digging concurrent features in PyQt, Adrian. >> Meanwhile I'll do it with QThread class or others :-) >> >> "Future" mechanism is good, no doubt. But if we decide to use it, >> it's difficult to refer our current GTK+ based implementation of >> the application base which communicates with Mercurial. >> It's a bit hard way, probably... :P > > Yeah. "Future" is bit too futuristic here I guess :-) > > But remember the pattern for your life as a (hopefully paid :-) programmer. > >> BTW, does that Phil's email mean PyQt doesn't support QFuture* >> classes in the future? >> > > I don't know. Judging from his answer, I'd say no. > > Using QThread should be fine. > > The best advice IMHO for our case can be found in the PyQt book in > chapter 19 in section "Creating and Managing Secondary Threads" > (you should really try getting access to this book, it's good - I now > have it on my safari account). > > The primary thread does method calls to the secondary thread and the > secondary notifies the primary by using Qt signals. > > Quoting the book: > > "Signals emitted in one thread that are intended for another work > asynchronously, that is, they don’t block. But they work only if there > is an event loop at the receiving end. This means that secondary threads > can pass information to the primary thread using signals, but not the > other way around—unless we run a separate event loop in a secondary > thread (which is possible). Behind the scenes, when cross-thread signals > are emitted, instead of calling the relevant method directly as is done > for signals emitted and received in the same thread, PyQt puts an event > onto the receiving thread’s event queue with any data that was passed. > When the receiver’s event loop gets around to reading the event, it > responds to it by calling the relevant method with any data that was > passed." > > The book demonstrates that in the pageindexer example (indexes HTML > files in a specified directory and all its subdirectories). The source > code for the book examples is available from > http://www.qtrac.eu/pyqtbook.html in http://www.qtrac.eu/pyqtbook26.zip > Navigate to the file pyqt\chap19\pageindexer.pyw in the zip. > > The code of the book examples is licensed under GPL2+, so we can even > copy/paste from it into TortoiseHg if we want (very nice). > Unfortunately, the book itself is not free. So you'll have to pay for > accessing it. >
Apologies, I guess I picked up the wrong link for the books examples. I think we should probably not depend on python 2.6 so we might have to use the older http://www.qtrac.eu/pyqtbook.zip in TortoiseHg ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Tortoisehg-develop mailing list Tortoisehg-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-develop
