Hey, You will find a solution in using KIO, as it was one of the design goals of KIO to keep applications reactive, when a server breaks away. KIO solves this by set up a connection only when reading/writing is needed. In contrast to fusefs that simulate a "normal filesystem", so you will face the hanging plasmashell also for sshfs or samba... But I have no more deeper insight in KIO, so I can't give good links... hefee On Mittwoch, 13. Juni 2018 20:20:07 CEST Martin Steigerwald wrote: > 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,
Attachment:
signature.asc
Description: This is a digitally signed message part.