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. ------------------------------------------------------------------------------ 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
