Hi all.
When several instances of Geany quit in the same time, there is a high possibility of a conflict. I can reproduce it easily on my machine, using either trunk or SM version.
To reproduce: open three instances of geany, "geany", "geany -i" and another "geany" (absence of file names implies -i automatically in this case). It would be better to open three different files in the instances, to distinguish them. Then logout or reboot without quitting geany manually. On my machine, after I (in case of trunk) or SM code (in case of SM) restart geany, the default session is always cleared. Expected behaviour: the default session is managed by the first of the three instances and contains the files, which were opened in that instance, after restart.
I can see two solutions for this problem. The first is an additional POSIX process-shared semaphore / mutex for Windows to guard geany.conf. This should eliminate the problem completely. AFAIK, there are no wrappers for process synchronization primitives in GLib, so I'll need to write a thin wrapper myself.
The second option is to change the behaviour of "new instances". If such an instance (#1) detects a "main instance" (#2) running, it should not touch geany.conf. Actually, to deal with the described issue, it is enough to implement this behaviour only when #1 tries to save geany.conf while quitting.
The second option is easier to write as it does not require additional synchronization primitives and it's possible to reuse the code of socket.c. Actually, I already have this option implemented, to check whether it indeed solves the problem. But, you see, this solution can't prevent the race condition completely, in distinction from the first solution. Moreover, some of you may consider the second solution "hackish", which is enough to decline it.
So, the first solution is right, but the second is easy :-) What do you think?
Best regards, Eugene.