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

[Duncan]

Sergei Andreev posted on Wed, 03 Aug 2011 12:39:01 +0400 as excerpted:

>> It's a plasmoid from kdelook, so not really a main kde problem,
>> *EXCEPT* for the poor plasma design choice of running all of plasma
>> single- threaded, so a single misbehaving plasmoid can either freeze or
>> crash the entire plasma-desktop.  That *DESPITE* the fact that the
>> trend these days is to have separate sandboxed processes for
>> everything, see chrome/ chromium, and firefox is headed that way -- but
>> still the quite new plasma just /had/ to be designed so a single
>> misbehaving plasmoid would kill it, even tho they were deliberately
>> making it extensible and inviting people of all sorts of skill levels
>> to design plasmoids for it, the VERY SAME reason chrome/chromium did
>> the sandboxed-process thing and firefox is headed that way!  They had
>> the opportunity to design plasma for robustness in that regard from the
>> very start, but didn't.  Now they have backward compatibility issues to
>> worry about if they try to fix the problem.  Oh, well... <shrug>
>>
>>
> 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 despite the fact that the flexibility of being able to 
run binary plasmoids of uncertain stability created by people of all 
talent levels was a design goal, they chose to use components that had 
poor performance characteristics when run in separate processes.

It /can/ work.  Witness how X handles all those independent processes 
creating their own windows, such that if one process crashes, it doesn't 
take down all of X!  There's this thing called a window manager that... 
manages windows!  What a concept!  And if one process crashes, its 
windows die, but those of other X-based processes continue!  What a 
concept!

So no, you (and Aaron) can't worm out of this by simply trying to shift 
the blame to the component, when the component was by definition a poor 
choice given the goal of the project to integrate all these binary 
plasmoids of uneven code quality... unless of course stability of the 
overall project just because some binary plasmoid created by some 
simpleton got it wrong, wasn't a goal.

Is that what we're supposed to take away from this, that plasma stability 
in the face of all those binary plasmoids of unknown stability wasn't a 
design goal?  Because that's what it looks like, given the argument used.

Meanwhile, there are plasmoidviewer and plasma-windowed, so at least
/some/ need for running plasmoids as separate processes is recognized.  
And krunner is also a separate process, because the need for that was 
recognized as well.  But for some reason it was considered acceptable to 
put all sorts of mixed stability binary plasmoids in the same process, 
where one of unfortunately bad design could take down the whole thing, 
then foist the whole thing off on components that were a deliberate 
choice for a project that had the goals of running all those different 
plasmoids of potentially differing stability... and now your argument, 
taken to its logical conclusion, is that stability in that context was 
NOT a design goal, at least of any serious priority, so choosing 
components with performance issues in the multi-process context that 
would prevent such stability issues wasn't a big deal?  <shrug>

Even simply setting it up so each desktop and each panel (container, to 
use the more generic term) was its own process, so crashing only took 
that down, not all panels and all desktops together, would be useful.  
Some sort of possibly dbus-based IPC could be setup for drag-n-drop 
between them -- using it for only that and other similar special-cases 
can't be /that/ performance-dragging, and panels are already either 
composited over top of the desktop if effects are on, or opaque, if 
they're off, so separate container processes could be composited -- or 
not -- just like windows from separate processes already are.

As for it taking memory and other resources that may be scarce on some 
systems, valid point, but remember, my original post favorably pointed 
out konqueror's options in that regard.  Set a same-process default if 
desired, but make it an option, and let the user decide where they want 
the tradeoff in terms of stability vs resource usage.

And yeah, having an entire panel/desktop/activity/container crash would 
still suck, but not near as bad as having all of plasma crash, with its 
multiple panels, multiple desktops and multiple activities.

That said, I don't claim to be a coder, and I'm obviously using it or 
there'd be little purpose to all the time I spend on the kde lists, so 
it's self-evidently tolerable.  I just wonder at some of the choices 
made, and if I see excuses for them that I consider "British Subway", I 
won't hesitate to call them as I see them.

("British Subway" == BS.  Not that they're any worse than, say, NYS; they 
may well be better for all I know.  But the initialism isn't correct in 
that case and back a bit over a quarter century ago when I was in high 
school, I had a teacher that used the "British Subway" euphemism, and it 
stuck...)

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