I just noticed: no more crashes! Thanks, KDE team!

[Duncan]

Kevin Krammer posted on Wed, 03 Aug 2011 14:46:31 +0200 as excerpted:

> On Wednesday, 2011-08-03, Duncan wrote:
>> Sergei Andreev posted on Wed, 03 Aug 2011 12:39:01 +0400 as excerpted:
> 
>> > And the answer is:
>> > http://www.freehackers.org/thomas/2009/11/10/wonders-from-a-kde-fan-
and-
>> > developer-about-some-kde-design-choices/comment-page-1/#comment-7507
>> 
>> Of course it doesn't perform well with each plasmoid as a separate
>> process... because they chose components with that characteristic.
>> 
>> That's the point.  It was a new thing so they could chose the
>> components they wanted, and [they chose poorly].
> 
> Actually no.
> It is mainly a problem of the underlying technology, i.e. embedding one
> process' window into another one's not being very well supported, or at
> least not on X11.
> 
> It is less a problem of performance, Konqueror has done plugins
> out-of-process for ever (incidentally making it the only browser to
> survive Flash crashes for years before other browsers changed to that
> model as well).

Valid and interesting point.  Not one I've had a lot of direct experience 
with since I won't do flash because it's proprietary, in the first place, 
but yes, it's valid, and kde has been recognized for it.

> But it clearly showed the limits of the underlying technologies used for
> that, e.g. the embedding process having little to no control over the
> embedded window (other than probably size and position) and embedded
> window having very few means of communicating needs to the host (and
> having two separate and exclusive event processing contexts).
> 
> So with basically forced to have all UI portions in the same process,
> running the data processing in separate execution units might be
> possible in some occasions without dragging down performance too much
> (as indicated by Aaron in the linked comment).

I can't argue with that, either.

But what about the other bit, where I suggested (rewording a bit) that 
(1), a natural process subdivision would be at the container level, that 
(2), while a whole individual panel or desktop container crashing 
wouldn't be as good as limiting it to an individual plasmoid, it'd 
certainly be far better than all of plasma including all panels, all 
desktops and all activities coming down at once, thus significantly 
limiting the damage, that (3), given existing behavior both with effects 
on and with them off, separate container processes each with their own 
window would behave very little differently in terms of composite, etc, 
and (4), that inter-container/inter-process communication could be 
reasonably limited without affecting performance /that/ drastically, 
while at the same time, /drastically/ improving robustness, just as it 
has with the separate krunner and as it does currently when for example 
using plasmoidviewer or plasma-windowed for plasmoid-development or the 
like.

It seems to be that would be a reasonable compromise, bypassing both the 
worst of the stability problems by limiting crashes to a single 
container, and the worst of the performance problems, because each 
container would then be its own window.  

The user experience I have establishing this includes running a separate 
superkaramba instance, set to top-dock so it's very nearly replacing an 
entire plasma panel.  It's /very/ nice to have that still running when 
plasma itself crashes or I shut it down and restart it.  Given that as 
I'm using it, it's almost replacing a full plasma panel... I still have a 
systray/notifier plasmoid on a short panel at the end... the concept has 
certainly been demonstrated to be effective here, and I'd very dearly 
love to see each plasma desktop (two monitors, separately configured 
wallpaper and plasmoids, separately crashing would be nice...) and each 
panel independent of the others process- and crash-wise, just as my 
superkaramba panel is independent of plasma.

As proposed, IPC could be used between desktop and panels for drag-n-drop 
integration, etc, probably implemented using dbus, and the performance 
hit shouldn't be any more critical than it is when dragging something 
between say dolphin and a folderview plasmoid.  Yet robustness would be 
HUGELY improved, because each panel and each desktop would survive a  
lockup or crash of one of the others.

...

Meanwhile, I did notice that the link mentioned konsole as suffering from 
a similar issue at the time, all konsole windows belonging to a single 
process.  That has apparently been fixed for some time, since at least 
4.5 I'd guess if not 4.3 or 4.4, as I routinely see multiple konsole 
processes and double-checked after reading the discussion -- using the 
xkill hotkey only kills the one konsole window, not all of them as it did 
back then. =:^)

Now if I could only kill one plasma panel/desktop/container at a time...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.