[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Hanging plasmashell

Jiri Kanicky - 13.06.18, 16:55:
> Any mounted system which looses connection will completely hang
> plasmashell.
> For example I mount NFS, close lid and take laptop to work and when I
> open it plasmashell is hanged.
> This has been issue for ages.

Any process which accesses a file from an NFS mount with the 
corresponding NFS server not reachable will by default hang for as long 
as the NFS server is not reachable.

This is how Linux filesystems work. Read accesses are usually in-process 
and applications waiting for those to be fulfilled will hang unless they 
use asynchronous (out of process) I/O.

The only way around would be to do all separate all filesystem accesses 
and the GUI painting into different threads or processes or use 
asynchronous I/O with its complexities in error handling everywhere. 
This has not been done for Plasma and I doubt it has been done for any 
other major desktop environment for Linux.

Of course for the plasmashell process itself the question would be: Why 
does it access the NFS mount anyway? Do you have some widget in the 
plasmashell that accesses anything from the NFS mount? If so, you would 
have to remove it. Most widgets run inside the plasmashell process. This 
indeed is a limitation of Plasma as it mostly has a all in one process 
architecture. Only KRunner and KWin window manager are separate. Most 
KRunner runners run in process… but there has been some work to 
background some costly operations recently if I remember correctly.

If plasmashell accesses the NFS mount while it would have no reason to… 
then that would be something for a upstream bug report.

I always thought a multi-process / multi-threading architecture for the 
desktop would be more suitable – especially in order to make Plasmashell 
more crash resistant with buggy widgets –, but according to what I 
remember what Plasma developers said, it is challenging to obtain an 
integrated graphical experience this way. I do not remember the details 
tough. I think I opened an upstream bug report years ago about this. 
Plasmashell uses some threads, but it does not appear that it uses 
different threads for filesystem accesses of widgets and so on.

Differently on AmigaOS. Even if the whole operating system filesystem 
was gone (i.e. by just killing the filesystem and device tasks for it 
which you could just do on AmigaOS as it is single user without memory 
protection, at least upto AmigaOS 3.x) the GUI was still responsive. At 
least those parts of the GUI that did not access the filesystem. And 
once running the GUI did not do many filesystem accesses anymore unless 
you triggered some.

So in summary: In order to achieve a responsive desktop with an 
unreachable NFS you´d either have to completely rewrite the architecture 
of the current Plasma desktop… or change the way the Linux kernel I/O 
subsystems works (and alongside of it probably also all the applications 
that use it). I´d really love to see a desktop that is always 
responsive. But so far I think sadly no integrated desktop environment 
with the functionality like Plasma has on Linux or any other Unix 
operating system is even close to that.

There is still something to be learned from operating system and GUI 
approaches of other operating systems like AmigaOS.


Reply to: