[Interest] Interest Digest, Vol 137, Issue 4

[Stefan Seefeld]

Hi Roland,

thanks for your feedback !
I partially agree with your analysis. In particular, I'm not entirely sure
why the entire application logic needs to gravitate around a single event
loop. For user-input events this of course makes sense, as they are
naturally ordered and so conceptually we don't need concurrency to model
the related control-flow. (We do need asynchrony, though !)

My main puzzlement stems from the fact that the event loop is used in
places where I don't expect it, such as in the handling of state machines.
Of course, state changes may well be triggered by user input (or some other
events), but they don't have to, so it seems questionable why the entire
state machine architecture has to be founded on the event loop as well. It
could be independent, with some mix-in classes that allow state machines to
interact with the event loop, without forcing such a dependency on everyone.

But to get back to the smaller scope of my original question, users don't
even have to access the main event loop via the
`QApplication::processEvents()` function; they can just create their own
local `QEventLoop` instance and use that. (Of course, under the hood that
has to interact with the main event loop, which is why this only works in
the presence of a global `QApplication` instance, but that interaction is
luckily already hidden from the user.)

My question is: Is it OK to use my own local `QEventLoop` to drain events
to render state-change requests synchronous. And furthermore, if the answer
is "yes", is there a reason why such a facility isn't already offered by
the Qt API itself ?

I'd really like to hear what Qt developers have to say about this, and, as
you suggest, about the broader question of how to scale Qt applications to
modern many-core platforms. How would users write modern C++-2x
applications while using `co_await` ? There already are adapters for the
Python equivalent, using `QEventLoop` instances to manage events and
dispatch control flow to multiple threads (e.g.
https://github.com/CabbageDevelopment/qasync). It seems to me what I'm
asking for is something similar, if not much simpler).

Thanks,

-- 

      ...ich hab' noch einen Koffer in Berlin...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20230204/0df61318/attachment.htm>