Re: [Inkscape-devel] Avoiding opening new instances
On Sunday 25 July 2010 01:40:13 Jon Cruz wrote:
On Jul 24, 2010, at 3:46 PM, Krzysztof Kosiński wrote:
There are only two sane approaches:
- Open every document in the existing instance.
- Open each document in a separate instance.
[SNIP]
Disadvantages of #2:
- slower start
- higher memory use - no data can be shared; if we use shared memory,
the crashed instance could have corrupted it and the stability guarantee goes away; possible solution: read-only shared memory, but hard to implement in a portable manner
One possible approach would be to use IPC to instruct a fully loaded inkscape instance to fork and open the other document (which should be faster than starting and fully loading completely new instance and allows OS to share memory for us in a copy-on-write manner). This should reduce loading times while maintaining a separate instance for a document (at the cost that any bad state caused by a bug will be copied to the new instance), at least for systems with reasonable fork implementation, I don't know how forks are emulated on Windows in ported unix applications.
On each build we can generate an UUID to be stored in inkscape-version.cpp and start a new instance if there's no instance with this UUID already running. There's a little more complexity in it, because we need to generate a different exclusion ID for every user session, so if you log in locally, start Inkscape, then lock the screen and log in remotely via SSH, you can start a distinct instance of Inkscape.
We also would need to tie things to different environment variables, etc. If one launches an instance of inkscape with different XDG variables from a current instance of the same version, things still should treat that as 'different'. And there are a few other such factors to consider. So it does look as if UUID itself does not solve the problem.
One such factor that comes into my mind is command line execution in scripts (with or without gui), the environment, user session, UUID, executable file path are not different between uses, while a new instance should probably still be used.
Regards, Martin Sucha
On 7/27/10, Martin Sucha wrote:
One possible approach would be to use IPC
D-BUS :)
Alexandre Prokoudine http://libregraphicsworld.org
2010/7/27 Martin Sucha <martin.sucha-ml@...2313...>:
One possible approach would be to use IPC to instruct a fully loaded inkscape instance to fork and open the other document (which should be faster than starting and fully loading completely new instance and allows OS to share memory for us in a copy-on-write manner). This should reduce loading times while maintaining a separate instance for a document (at the cost that any bad state caused by a bug will be copied to the new instance), at least for systems with reasonable fork implementation, I don't know how forks are emulated on Windows in ported unix applications.
I didn't think about it. It looks like a promising idea. Windows has ZwCreateProcess, which is an undocumented NT function that works like fork() including copy-on-write shared memory between the parent and child processes, so in principle this is possible. It would be wise to push the Win32 fork() implementation to Glib before using this.
We could have one "master" instance that does all the initialization, handles preferences file writes, registers itself on DBus, and forks the "slave" window processes. The code executed in master after initialization should be reduced to minimum, so that a bug is unlikely.
One such factor that comes into my mind is command line execution in scripts (with or without gui), the environment, user session, UUID, executable file path are not different between uses, while a new instance should probably still be used.
We should do the following: if the option parsing bit decides that we are being run in non-GUI mode, we should not contact any other processes. If it decides we are being run in GUI mode, we should submit the results of option parsing to the master process, which will take care of performing all the work described in the command line.
Forking a process from master when in command-line mode could sometimes be desirable, as it would speed up the execution of many Inkscape commands in quick succession.
I also have to admit that it gets really complicated with forks, the master process, etc. so going for the simpler but less stable single-instance solution might be better for now. Once there is a fork() implementation in Glib, and the D-Bus binding and GSettings get merged into GIO (which should happen soon), we could start working towards a multi-process architecture.
Regards, Krzysztof
On Jul 27, 2010, at 9:06 AM, Krzysztof Kosiński wrote:
I also have to admit that it gets really complicated with forks, the master process, etc. so going for the simpler but less stable single-instance solution might be better for now. Once there is a fork() implementation in Glib, and the D-Bus binding and GSettings get merged into GIO (which should happen soon), we could start working towards a multi-process architecture.
So what is the current state of D-Bus on Win32? Is it stable and released now?
W dniu 27 lipca 2010 18:46 użytkownik Jon Cruz <jon@...18...> napisał:
So what is the current state of D-Bus on Win32? Is it stable and released now?
It still requires some work, but there is a plan to fix it in the GTK 3.0 timeline.
With regards to fork() on Windows, this PDF contains an example implementation of it starting on page 161: http://multi-desktop-manager.googlecode.com/files/NativeAPI.pdf There are two problems: 1. It calls some magic private routine in the kernel using a hardcoded address that is not consistent between kernel versions (service packs). Text says this is done to overcome a limitation in kernel32.dll and there is no good solution. 2. It uses a naked function which might not be supported by GCC on x86. 3. Some Windows DLL initialization procedures do not work correctly, because their correct function depends on the initial values of global variables.
Therefore, I think using fork() on Windows might not be feasible.
Regards, Krzysztof
A follow up about solution #1 (single instance). The future way of doing this is using GtkApplication. Maybe we should wait for GTK+ 3.0 instead of creating an inferior solution.
http://library.gnome.org/devel/gtk/unstable/GtkApplication.html
Regards, Krzysztof
Krzysztof Kosiński wrote:
A follow up about solution #1 (single instance). The future way of doing this is using GtkApplication. Maybe we should wait for GTK+ 3.0 instead of creating an inferior solution.
http://library.gnome.org/devel/gtk/unstable/GtkApplication.html
Nice, that would definitely be worth waiting for.
participants (5)
-
Alexandre Prokoudine -
Jasper van de Gronde -
Jon Cruz -
Krzysztof Kosiński -
Martin Sucha