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