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.
