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...
_______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest