[Bug 287002] panel freezes

Sergio sergio.callegari at gmail.com
Tue Mar 13 11:05:54 GMT 2012


https://bugs.kde.org/show_bug.cgi?id=287002

--- Comment #102 from Sergio <sergio.callegari at gmail.com> ---
To mountainX:
In my own experience, USB3 tends to be a problem of its own.  On kernel 3.0.0 I
have may issues with it, including the kernel (not just the desktop
environment) becoming unresponsive and hanging on some USB3 related situations.
 So I would wait for USB3 support in the kernel before assuming misbehaviour in
DEs with respect to USB3.

For the rest, the updated nm plasmoid has fixed most if not all the plasma
desktop freezes for me.
What remains an issue is that the plasma desktop at times uses what seems an
excessive amount of resources (e.g. 20% cpu).

This brings me back to what is IMHO the most important point.
For efficiency reasons, the plasma desktop designers have chosen not to use
lightweight kernel threads for the plasmoids, but to implement their own
cooperative user-thread mechanism. Unfortunately, at this point there are no
tools to check the quality of the cooperation that the individual plasmoid may
offer. If a plasmoid hangs, all the desktop hangs and there is no automatic
identification of the faulty plasmoid. If a plasmoid causes the plasma desktop
to use an excessive amount of CPU time, similarly there is no means to find out
who is to blame (unless one wants to disable and re-enable the plasmoids one by
one).

I think that the real issue now is that for anyone it is way to easy to put the
DE into a crises. In principle this could be even done maliciously. Say that Mr
Eve hates KDE and wants to throw a bad light on it. He can make a plasmoid that
looks very fancy, to get tons of people install it and designs it to be a bad
citizen on the plasma desktop. This is enough to have many many people's KDE
desktops hanging. Since the cooperative threading framework cannot recognize
the faulty thread, people will blame the DE, not the evil plasmoid.

-- 
You are receiving this mail because:
You are the assignee for the bug.



More information about the Unassigned-bugs mailing list