When Google Chrome first came out sporting its process separation feature where each tab is in its own process, it was broadly hailed as the best thing ever. The idea was to increase stability and security.
This was during a time when Plasma Desktop was still facing a number of implementation hurdles that impacted stability. So a number of well-meaning people decided that I should be informed about this revolutionary new idea in Chrome and every component in Plasma Desktop should be put into its own process.
This was applying a solution from one problem space to another that just didn't map at all. For technical reasons it was not feasible and I offered alternatives. Still, there was a good year or so when pretty much every single day I would get at least one message from someone suggesting we redesign Plasma to be separated across different processes. Some were kinder than others, but after a while even the nicest of people sounded like fingernails on a chalkboard.
Since then we've moved on to the alternative approaches we identified well before Chrome was even available: interpreted rather than compiled code. Today we're walking with both feet into the brave new world of QML. As of Qt5 we have QML2 which brings with it scene graph based rendering that can be done in hardware where available and a runtime that makes writing beautiful interfaces that are also stable very easy. It has been a long road to this point and has involved countless dozens of bright people working hard.
In the meantime, how is that process separation in Chrome working out? Here's the conclusion of one analysis based on actually measuring things: "The [process separation] mechanism is based on a relatively dated concept, superseded by compile-time code validation techniques such as Google's own Native Client [..]
An unintended consequence of this design is that all attempts to synchronize the state between two processes are inevitably very expensive. [..] It seems that the apparent improvements in the stability of Chrome come at a very significant cost; and that unless the architecture is revised substantially, it may hinder the development of tightly-integrated and highly responsive web apps."
I don't hold quite so dim a view of process separation used in the right places as one might come away with after reading that article, but it is a cautionary tale about believing in silver bullets. Different problems are different and very few design concepts carry only benefit with no cost.
Subscribe to:
Post Comments (Atom)
15 comments:
I find process separation very distasteful. It makes sense for running things you do not control (like plugins) in a separate process. But if you are writing something and want to run it in separate process then this means that you need to learn more to create better designs for your code.
Well done aseigo. Each applet in a separate process would have been bloated beyond thought. I would prefer Plasma to be good enough to handle that case.
Would it even be possible to run each applet in its own process? As far as I know some architectures/operating system have a limited no. of processes you can run... (this might be more relevant for embedded systems then desktop systems)
There are many technical arguments against process separation which make it a bad approach. The same kind of reasons why boost signals are more efficient than Qt signal/slots, why normal pointers are more efficient than smart pointers and why compiled languages are faster than interpreted languages.
That's the theory. The real question is: what is really relevant for the users? The performance impact is there but is usually not noticeable. The absence of crash is however a big benefit for the user. Safety should be the first priority and as error-free applications is a utopia (perfect code does not exist), it is a good idea to at least make some kind of boundaries to make sure than a crash will not affect too many things. The same reason why fire-doors still exist today.
In my opinion, the separation between data engines (when it will be possible to run them in separate processes) and UI (QML + interpreted language) is good enough and the decision to stick to an interpreted language for the UI makes sense. Please be aware, however, that it does not guarantee 100% safety (for example, endless loops are still possible...).
Really interesting point of view. Trends are just trends. It's not that easy to see the forest in the trees, so kudos for that! Or as Henry Ford would say:
“If I had asked people what they wanted, they would have said faster horses.” ― Henry Ford
Nitpick: "As of Qt5 we have QML2 which brings with it scene graph based rendering"
s/QML2/QtQuick2/
QML is not involved in rendering at all :)
@Benoit - single process is not the same thing as single thread. Individual threads within a process are interrupted to allow all processes to progress.
However threads are not isolated from each other like processes, if one thread crashes, for example because it tries to access something in the memory which is no longer there without checking or handling the error, then the whole process will crash.
Managed code can create an environment where this sort of error is impossible.
Declarative and/or interpreted client code makes also makes it possible to change the concurrency model for the code. For example (and I have no idea whether this is done currently) re-writing blocking i/o into a continuation-passing which can have a huge performance benefit over relying on "blind" operating system threads to resolve blocking.
on which subject...
Aaron - I'm interested in what parts of the Qt5 and KDE5 API are/will be asynchronous by default but I'm really struggling to find any sort of discussion about it. As far as I can see Qt's file API is blocking only. If you could point me towards where to look I would be very grateful.
@maninalift: I did not write anything about threads in this thread :) As far as I know, the QML/Javascript part of all plasmoids will be running in the same process *and* in the same thread because they are all using the same declarative engine. That's why an infinite loop in the UI part (not in the data engine) can lead to a freezing desktop. The risk is there, but that use case *can* be neglected (as long as you can trust the plasmoid developpers...).
I don't really see how QML is going to be a panacea here. In-process QML can bring the whole process to a halt just as easily as C++.
OTOH it is true that QML2 should enable composition a lot easier, since you can send OpenGL textures around and throw it together (WaylandSurfaceItem FTW). 5 years ago it didn't make sense to do composting because we wanted to support legacy stuff as well. It just wasn't possible. QML2 means it's now an option for plasmoids to be in a separate process.
@maninalift: "I'm interested in what parts of the Qt5 and KDE5 API are/will be asynchronous by default"
anything using sockets (of course :), dbus, QML loading/parsing. as for file operations, stuff those in a thread to get async behavior.
@Ian Monroe: " In-process QML can bring the whole process to a halt just as easily as C++."
Just as easily? No. Try derefencing a null pointer in QML.
Can it bring the whole process to a halt? Currently, yes. However, as it is a *runtime* we have the possibility of addressing those kinds of issues as well.
"QML2 means it's now an option for plasmoids to be in a separate process."
* this will inevitably be slower
* it doesn't mean "no crashes"
* visual and functional interaction between components in different processes in the same canvas? that is a straight-out pipe dream.
if we put severe constraints on what a component can and can not do then they could all be in their own process. the problem is we want something that is dynamic, fluid and beautiful.
@Aaron:
while I agree that the overall performance of a single process will be "theoretically" better (although you tend to exaggerate the performance overhead which is actually unnoticeable), a bad-coded plasmoid can slow down (or even freeze) the plasma desktop. That's a risk which is minimized thanks to the current design (data engine, GUI + QML/Javascript). But because all plasmoids (incl. the taskbar!) are in concurrence, the user experience *is* affected and that's probably more important than the tiny overhead of a separate process.
The main reason why separate processes may not be the best option is, besides the technical difficulty of using composition, the memory overhead. A bare Quick2 application requires more than 10MB, IIRC. Core plasmoids could be differentiated from 3rd-party plasmoids, though.
Regarding the interaction between components, this is not more needed than any interaction between traditional applications. While I'm not sure the priority should be higher than the enhanced stability, you may find a concrete use case for it.
@Benoit: "this is not more needed than any interaction between traditional applications"
Yes, actually, it is. It is not only a core a design requirement we placed on Plasma quite purposefully, but it is a feature that is used extensively throughout.
Can you appreciate the frustration of having this sort of discussion repeatedly with people who do not have a grasp of the subject they are talking about? :)
@aaron:
We can of course debate about the possibility of knowing and determining "who knows who has an idea about which subject", but the question here is to understand the decision single vs separate process. And in that case, I am trying to understand which kind of integration is not possible with separate processes and composition. There might be better explanations than "beautiful" and "visual integration" and maybe even use cases. There might even be a discussion about it.
@Aaron
anything using sockets (of course :)
of course, the Qt API has been a leader in this.
dbus,
Thanks I'll have a look at the API
QML loading/parsing.
That was the the one thing that _did_ turn up repeatedly in my searches :¬)
as for file operations, stuff those in a thread to get async behavior.
that is some combination of difficult and inefficient depending on how much work the programmer is willing to put in. The first of these is the worse problem since it means that in practice in many, possibly most, cases client code will use blocking io.
The only answer is to make the io API itself asynchronous, whether it uses callbacks, signals, futures or some other mechanism.
I hope this doesn't raise hackles when I mention it but Microsoft decided that the Windows 8 runtime would only provide asynchronous API for any calls which could possibly take more than 50ms. The approach they have taken is to employ futures. In general I much prefer using KDE and Linux (home) to Windows (work) but so far I have been really impressed by the results (assuming I can out the improved responsiveness between 7 and 8 down to this change).
For my money I think this is (becoming) an important topic on the Desktop, but the place it's impact can't be ignored is in power-sensitive form-factors such as tablets and phones.
Thank you for your answers I will at the very least look into this some more.
I don't know if the report you linked is good or not: the link isn't reachable.
One thing though: Chrome *can* put all your tabs in the *same* process if you configure it to do so (command line option), so it is quite flexible here.
Running each applet in its own process may not be a good idea in normal usage, but I wonder if this wouldn't be a good idea to troubleshoot issues..
Aaron,
As a security geeks who works on KDE when I have the time, I think your comments on processes vs validation are a touch misguided.
The validation in Chrome used for NativeClient may be better than most but it's still been exploited and moreover, there are plenty of examples of in app sandboxes that have been significantly less effective - notably the king of all sandboxes Java.
Using out of app controls such as SELinux, process, namespaces, chroot() etc, all benefit from the fact that trust is then spread between two independent development teams.
Furthermore I would note that rather than consider separation of process or validation as being sufficient on their own, Chrome uses both + seccomp + namespaces + other defensive mechanisms.
I totally get the point that process separation isn't going to be appropriate for all of Plasma but there are certainly places where it might be a nice option to have. Network focussed applets would be a good example.
Tim
PS Be nice to see Konqueror benefit from some of the Chrome developed sandboxing techniques.
Post a Comment