[Interest] Is QEventPrivate a remnant?

[Nye]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160212/f6298f94/attachment.html>