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, -- Martin
