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.
Thanks,