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

Re: Hanging plasmashell


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


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.

Reply to: