Hello, The only reason to subclass one of Qt's QXxxxPrivate classes is if you're > developing something as part of Qt. > > If you're feeling adventurous, you may want to access one of those classes, > without deriving from them. But you're still accessing private API and > you're > subject to the "We mean it" comment in the header. Your binary will be > tagged > on Linux as "Qt5_PRIVATE_API" and Linux distros will give you a dirty look.
At some point I might try opening a module in the playground (not sure if that was the term), although at this point I'm trying to make something work. :) How do MPI messages come through normally? On a Unix system, there are only > two possible sources of events: file descriptors and timers. On Windows, > there's a third (HANDLE events, for which there's QWinEventNotifier). > > Why couldn't you use one of those and build upon it? > Unfortunately, the messages are polled, and I have seen, browsing through the OpenMPI docs, no way of using a file I could select upon when a message had arrived. To check for pending communication, one issues either MPI_Iprobe (non-blocking) or MPI_Probe (busy-wait) to check/wait for a message coming through the library. Additional restrictions are that I'm supposed to have that running on a single thread (the cluster job manager kills my processes if try starting a thread), so I couldn't make this polling in a worker object for example and just signal the application as messages arrive. In the qt forum (http://forum.qt.io/topic/63816/qt-openmpi-wrap/5) I've put some thoughts, although one wouldn't call the discussion lively. What I'm currently doing is just running an endless (non-blocking) loop, processing MPI and then calling the default dispatcher implementation to process any pending timer events. Basically, my processEvents() override consist of a single row: bool QMpiEventDispatcher::processEvents(QEventLoop::ProcessEventsFlags flags) { return processMpiEvents() || EventDispatcher::processEvents(flags & ~QEventLoop::WaitForMoreEvents); } The non-blocking character of the loop is not worrying me, because as I've mentioned MPI_Probe (the "wait for a message") is implemented as a busy-wait. The reason for that is somewhat unclear, but I always assumed it's because the MPI communication is (supposed to) run on a low-latency high-throughput network (the cluster I've been using is employing infiniband). To pile up, the blocking probing doesn't provide a means for interruption or at least to set a timeout. > Yeah, you *can* do it. You just shouldn't. > > Maybe what we need to do is discuss how to integrate OpenMPI better into > Qt, > so you don't have to have those hacks in the first place. This works great for me, provided you have the time and are willing to discuss. I realize that this is somewhat obscure task, as not many people will be wishing to run a Qt application on a cluster. That notwithstanding, any and all suggestions are welcome! You're not breaking binary compatibility because you didn't modify Qt. But > you > are subject to compatibility on symbols that don't guarantee it. The "We > mean > it" comment applies. I meant I'm breaking compatibility between my library (where I'm implementing all that hack-ish stuff) and Qt, so I must rebuild my library with each new build of Qt; I have been warned by QtCreator. Qt itself is still very much binary compatible, as you pointed out. Kind regards, Konstantin.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
