[Gtk GUI] User interface: dnfdragora freezes on start for a very long time

[genodeftest]

It seems like dnfdragora is freezing very often on start. Sometimes it does recover, sometimes it does not. This might be the result of some background operation going on, but since there is no busy indicator (except a spinning wheel) the ordinary user would not know if there is. After some time dnfdragora sometimes starts displaying information on the fact that it is updating repo metadata.

I'm running dnfdragora-1.0.1-1.fc26 with libyui-3.3.2-1.fc26 and dnfdaemon-0.3.17-1.fc26.

[anaselli]

the indicator is the busy cursor, in addition the progress bar is used when dnf-daemon sends data for it. So if you can't understand that is working i need to know what is really happening, because i need to reproduce this problem and i seem not to here.

[genodeftest]

That's the problem, I don't have reliable steps to reproduce. Often it is just

1. start dnfdragora
2. wait for it to stop having a busy cursor

and this could take a while, I've seen more than 60 seconds once, without any progress bar or status text shown.

[anaselli]

you said libyui-gtk right? which which desktop?

[genodeftest]

you said libyui-gtk right? which which desktop?

Yes. GNOME + Wayland.

[anaselli]

I will make some tests as soon as i configure a vm with gnome. Just a shot in the dark... could this problem be related to the update notifier? I mean dnfdragora does not have one, but i suppose fedora is still shipping its one, so maybe a conflicting dnf db access that is not managed as expected could be a reason... Are you able to make some tests for this?

[genodeftest]

Yes, this could be the update notifier. I also notice this behavior if I use dnf as root from a command line, then dnfdragora also waits very long until it even starts showing the progress bar. Using the update notifier or dnf (as root) in parallel worked fine with yumex-dnf, at least until Fedora 25.

[anaselli]

So it seems a good catch after all :) I will investigate that first then comparing also the yumex-dnf code. Thanks

[kn00tcn]

my yumex-dnf has been slow for probably months by now, as is manually doing 'dnf update' & waiting for the 'updating metadata' to appear, during this time there is heavy drive activity

so are we sure this has anything to do with the frontend?

[asl97]

Last I recall, yumex-dnf UI doesn't freeze, only grey out a few stuff but still allow interacting while it does stuff.

dnfdragora on the other hand just freeze and doesn't allow interacting, basically it's non-responsive in a lot of instance like startup, search, apply,

Additionally, despite there being a blinking insert bar, typing doesn't do anything while it's doing stuff.

[kn00tcn]

dnf's commands are locked during this time though, it's busy dealing with metadata, same amount of waiting when you run it from terminal & wait for a response

[asl97]

While dnf may be lock, it still shouldn't freeze the interface, that just a bad UI.

Yumex-dnf ui doesn't lockup, you can still switch panel and open it's settings (including repositories) while it's dealing with metadata.

There are plenty of stuff which shouldn't need dnf like dnfdragora 's user preference, manual and about.

Not to mention, on a non-compositing desktop, the user experience is even worse.

^ Do not misunderstand though, when switching to it, it's completely whatever that was displayed before it and the bar will get superimpose on it when it updates.

[kn00tcn]

ah right, the settings

but there's so little in them, making it a rare situation

edit: compositing issue might be libyui's fault (unless it's somehow related to dragora temp freezing the ui until it's ready with the check?)

[anaselli]

Not to mention, on a non-compositing desktop, the user experience is even worse.

^ Do not misunderstand though, when switching to it, it's completely whatever that was displayed before it and the bar will get superimpose on it when it updates.

I can't see such an empty dialog even on old dnfdragora, how can you get it?
Is the progress bar related to caching groups or just for metadata at startup?
BTW dnfdragora can't do anything if data from dnfdaemon is not ready so we can try to make (maybe) confortable this waiting, but that time must be waited. It seems odd to me that yumex-dnf allows package queries during metadata download... I maybe wrong...

[asl97]

@anaselli LIke I mention below the image, it's due to a non responsive ui.

Does this image help? This image is created simply by dragging a terminal around the dnfdragora window.

yumex-dnf grey options that aren't available during any background activity but doesn't become non responsive (thus doesn't end up like dnfdragora).

dnfdragora can and should still process ui event while waiting for data, it shouldn't need any dnfdaemon data to open it's setting, resizing it's window or generally interacting in anyway with already available data (ie: expanding groups).

[anaselli]

so are you using groups? that is important. Because that part is not handled by dnfdaemon (i hope just for now and be in the future), if it is that then i can try to use a slower VM to reproduce the behavior and try to better manage that. But if you have such a behavior interacting with dnfdaemon, i think it isn't easy to reproduce it here...
and UI events are managed by libyui that is not managed as threaded, so a single thread only, that's why i added a busy cursor there that should redraw the windows and should not freeze it.

[asl97]

Adding a busy cursor doesn't cause it to redraw nor stop it from freezing.

You need to call ether self.dialog.pollEvent() or self.dialog.waitForEvent() for it to redraw.

All UI stuff should be moved to it's own thread so that it doesn't freeze.

[anaselli]

it seems you know more than i thought... maybe you could provide a patch 👍
I will be happy to review and add it ;)

[anaselli]

I was able to have a similar situation, yes frozen windows is very annoying. Busy cursor when is set does it jobs though, does not allow to use the window and at the same time does not freeze. The problem is that some tasks that normally requires little time or atomic operations (such as at start time dnfdaemon connection) are not always covered by busy cursor so in that case the windows is frozen.
I'm not sure it could be moved to a thread in an easy way, but i would think a bit to it. Patches are welcome anyway :p

[asl97]

Expecting someone who doesn't know the code base to rewrite the main event loop might be a little bit much.

Is there an IRC channel or something where it would be easier to ask/discuss about the code?

[anaselli]

Sure #manatools and #libyui

[asl97]

I am just going to leave what I manage to do here: master...asl97:ui-threading

It's mostly just a Proof of Concept, while it doesn't freeze while opening or a number of other places, it still freezes when the backend thread is (cpu) busy.

If the maintainers feel it's good enough to be included as is, they can create the pull request and merge it.
Do note that I ain't willing to maintain this code nor can I promise to answer question about it.

Base on this PoC, preventing freezing seem impossible using threads due to the GIL which I believe is the cause,
multiprocessing might work, however since the processors doesn't share state, it would need a lot of work to properly and totally separate the ui from backend, more than what I am willing to put in.

[anaselli]

Thanks you did a lot of work, i will take a look as soon as possible. I do hope, in any case you won't disappear :)

[anaselli]

are you sure you commited all?
Got the following exception:
'mainGui' object has no attribute 'handleevent'
And after that. it does not exit well it needs a kill operation

[asl97]

I did, handleevent has been renamed, it's the first line of diff in the compare.
master...asl97:ui-threading#diff-36ffa1050382553eb32fb5b399e8aa81L85

[anaselli]

my fault, sorry. anyway I think a change should be added in updater.py