GNOME Bugzilla – Bug 583680
evince should allow multiple processes
Last modified: 2009-10-20 17:20:57 UTC
Currently, evince uses a single process to display all documents. Unfortunately, evince still has crash bugs (which I try to report), and it probably will have them for the foreseeable future. However, I often have 10+ documents open, collecting data from all of them. If I happen to open a bad PDF, all of them will crash. It can take a lot of time to find the documents, and the right pages again. A different bug is also caused by the "one process, many documents" model: https://bugzilla.redhat.com/show_bug.cgi?id=456475 The single-process model also potentially opens the door to privilege escalation bugs, where the initial instance of evince is allowed to do something that the subsequent ones would not have been. Memory, on the other hand, is cheap, and the overhead of separate processes can be low (see, e.g. Google Chrome). Thus, I propose that it would be a good idea to have evince (at least *optionally*), behave as a single window-single process application.
Evince recovers now the previous session when it's run after a crash. See bug #578894. You can avoid single-process by building evince without DBus support. Thanks for reporting.
Is it a lot of trouble to add make a runtime switch to disable this single-process behavior? For example, gnome-terminal, which needs multiple processes a lot less often than does evince, has a nice "--disable-factory" option which does just that. I have some doubts about using a factory design for evince in the first place, but that's probably not the right forum for this discussion :)
I think it's not about recovery indeed. It's about stability, one document shouldn't affect others. That's why browsers move for multiprocess for example. We could also do this way and benefit from memory protection and bug isolation but the issue here is cooperation with metadata storate.
*** Bug 585403 has been marked as a duplicate of this bug. ***
One of the main features that take advantage of the single instance approach is metadata, however it wouldn't be necessary if we use GIO to store the metadata (see bug #586841) instead. Is there any other feature that justifies single instance?
> Is there any other feature that justifies single instance? How about the feature where we present an existing window when you open an already open file again?
(In reply to comment #6) > How about the feature where we present an existing window when you open an > already open file again? > Good point. This might be implemented with dbus, similar to gvfs approach, a general daemon that routes messages and one process per mount (per document in our case).
hmm, there's another thing we should handle in a centralized way, the crash recovery stuff. I think normal session management can be handled separately by every window/process, but the crashed session have to be handled somehow by the main daemon.
wait, I guess crash recovery doesn't make sense anymore in multi-process approach ...
Fixed in git master.