Differences between quamash and asyncio event loop + processEvents

Hello,

I was wondering what would be the implication of using the asyncio event loops for a Qt application instead of quamash Event loop.

We can use asyncio with Qt with the following simple code. The app must be killed to be stopped but you get the point :

    async def process_events(qapp):
        while True:
            await asyncio.sleep(0)
            qapp.processEvents()

    qapp = QApplication(sys.argv)
    loop = asyncio.get_event_loop()
    loop.run_until_complete(process_events(qapp))

So what does Quamash brings in terms of compatibility and stability with the Qt system compared to asyncio event loop ? Or is it only about a proof of concept ?

The first thing I can see is that asyncio + modal dialogs does not working easiliy. But I wonder if there are more things to know that I’m not aware of ?

Thanks

[enkore]

A major difference I didn’t see mentioned here is quamash only working for the main application event loop, i.e. QApplication’s main/UI thread. Meanwhile the “let’s put an event loop in an event loop so you can loop while you loop”-approach actually works for arbitrary QThreads. Sample code:

class ...(QObject):
    @pyqtSlot()
    def run(self):
        # Connected to QThread.started; thus will be called in the new thread.
        asyncio.set_event_loop(asyncio.new_event_loop())
        self.evloop = asyncio.get_event_loop()
        self.evloop.run_until_complete(self.run_event_loop())

    async def run_event_loop(self):
        """
        Runs the event loop. Will only complete if the thread receives an interruption request
        (QThread.requestInterruption()).

        Since we are using asyncio only for coordination, the loop will block for Qt events.
        """
        thread = self.thread()
        while not thread.isInterruptionRequested():
            await asyncio.sleep(0)
            thread.eventDispatcher().processEvents(QEventLoop.AllEvents|QEventLoop.WaitForMoreEvents)

The sequence to get such a thread to join is thus as follows:

thread.requestInteruption()  # Set interruption request flag
thread.eventDispatcher().wakeup()  # Causes processEvents() to return even if no real events arrive
thread.quit()  # Causes event loop to quit (the one running in QThread.run, not run_event_loop())
thread.join()  # Thread will exit now and can be joined.

I am using this in the context of QNetworkAccessManager, where I have the ability to retry requests and such things, but I also wanted to avoid the signal/callback-oriented approach, since that tends to get messy fast.

Thus, the actual events driving this and completing futures is the QNetworkReply status slots explicitly setting the results on futures previously created. The event loop of asyncio is only around to resume coroutines as the futures they’re waiting on enter done status.

[Insoleet]

Ok so I did a fast implementation of the option ( https://github.com/Insoleet/quamash/tree/perfs ) :

• use a single simple timer and key off the timerId more

This implementation breaks Executor tests, and notably the ones about subprocesses , but it was enough to run the benchmark.

It looks a bit better but that still not as good as standard asyncio :

Results for run_aiohttp
RPS: 1017,  mean: 477.999 ms,   standard deviation 70.280 ms    median 468.330 ms
Results for run_aiohttp_quamash
RPS: 699,   mean: 694.200 ms,   standard deviation 105.264 ms   median 689.685 ms

Any idea maybe ?