On 24 February 2010 20:04, Eugene Arshinov
<earshinov@gmail.com> wrote:
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.
The overall issue of preferences, configuration and sessions for multiple instances is an interesting one (Sorry Eugene, I've got no answers but lots of questions)
Why is the first necessarily the "master"?
Is this by definition or is there a reason?
What if the first is started with -i?
And what happens to configuration changes I make in other instances?
You see, I'm forgetful, if I had more than one Geany running (and I can see good reasons to do that) then I may forget which one is the "master" and change a preference in a different instance, so what happens to the conf file?
These are questions beyond just the session manager I know, but maybe the answer is/should be the same.
Cheers
Lex
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.
_______________________________________________
Geany-devel mailing list
Geany-devel@uvena.de
http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel