Make loading updates async from main AppCenter window

[hanaral]

What Happened

Trying to do a search for example, will make the AppCenter lock up for a while if the AppCenter is loading a large amount of available upgrades in the background

Expected Behavior

The updating process is seperate from the fronted so that the user does not face lockups just trying use the app normally

Steps to Reproduce

1. Open AppCenter and immediately try to search
2. It should chug (or even lock up in the case of my install HDD on my desktop)

This seems to be less obvious with an SSD, but you can still see it freeze for a second even with a small number of available upgrades

Platform Information

elementary OS 6 Daily
Tested on Lenovo ThinkPad X240 and desktop with AMD Ryzen 3 1200 & RX 570

[ids1024]

I don't know if there's any good tooling to check what is blocking an application's main thread, but running in gdb and hitting ctrl+c when the UI is blocked is one way to get a trace of what seems to be blocking.

One thing I'm seeing is the call to Flatpak.Transaction.run in FlatpakBackend.get_download_size_by_id. That function is async but the documentation for flatpak_transaction_run explicitly states "Note that this call blocks until the transaction is done.".

I think there are various other issues like that (in both the flatpak and packagekit backends). Given there doesn't seem to by an asynchronous API for this, presumably all such calls into libflatpak should be in a separate thread or process.

[davidmhewitt]

@ids1024 Most of the long running operations in the Backend classes are already run in a separate thread. There's a thread pool and a pattern of a public async method queueing up work via a private internal worker method on that pool.

You'll definitely see that for the install/update/remove methods. It's possible that this specific one was just missed for some reason.

[ids1024]

Yes, most of those operations happen in a background thread, but this issue seems to exist due to a few that do not.

It seems like there should be a good way to profile what functions are blocking the UI thread. That would help for getting a more complete picture of what issues there are here.

[davidmhewitt]

I believe sysprof's "speedtrack" should be able to identify blocking I/O happening on the main thread.

[aral]

I’ve noticed that checking for app updates blocks the main thread rather considerably (to the point where I thought the app had hung the first few times it happens). I can reproduce every time I launch AppCenter.

[danieleiervo]

A full year is gone and I can still reproduce: are there any updates on this?