[Interest] Is QEventPrivate a remnant?

[Nye]

>
> That's not what I meant. I meant that you run your APIs in non-blocking
> mode.
>
> There's only one thing in each thread that is allowed to block and that's
> the
> main loop, the one that QCoreApplication drives.


I'm already running the MPI API in non-blocking mode.

I meant that if you need to poll, you use the aboutToBlock() or awake()
> signals, and poll at that point. Obviously you won't receive notifications
> as
> early as they're available, because the event loop is blocked, waiting.
>
> But this is what you have today and you'll have the same functionality
> without
> having to use private classes.


Wouldn't that mean that once aboutToBlock() signal is emitted and I poll
for messages, provided I have none the loop will block, and unless I have a
system event pending (a timer or a socket/file notifier) it will never
unblock? Reading your comment, however, I think that maybe it'd better to
poll on a regular timer event (coming from a QTimer) instead of doing it at
the low-level ... what do you think?

Kind regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20160215/782350ad/attachment.html>