Thomas HERVE wrote:
The next QT version (4.2, currently in RC1) contains support for the Glib eventloop. This has to be tested, but it promises use of the gtk reactor with Qt application. Qt 4.2 (and PyQt) is not released but should be by the time of Twisted 2.6; we could then write a documentation about integration. The drawback is that you'll need glib (ie, python-gtk) to write a Qt app.
We also have a qt4 reactor (http://twistedmatrix.com/trac/ticket/1770) that needs a maintener. Last time I checked few things were needed to make the test suite pass.
As far as I am aware (and please correct me if I am wrong) all these recent qt-specific reactors have the same systematic problem on win32 because they rely on hooks into the Qt main loop. This means that the reactor only processes events when the Qt main loop is running, and it stalls if the main thread blocks in some nested non-Qt message loop. This is a reasonable thing to happen in a GUI application; nested message loops are used in MessageBox, drap/drop, window resizing, and non-Qt dialog boxes (like the standard file chooser). The nested message loop will be doing the win32 GetMessage/DispatchMessage dance. This is sufficient to keep the GUI updating smoothly, and it should be sufficient for the reactor too. IMHO threadedselectreactor seems like the best option for getting *this* right. glyph wrote:
threadedselectreactor is an interesting concept but hopelessly broken and untested in its current implementation.
Im currently using threadedselectreactor (plus private patches) and a derivative threadedwin32eventreactor in production, so this statement leaves me with a fairly big itch to scratch. I will check out the failing tests.