<br><br><div class="gmail_quote">On 24 February 2010 20:04, Eugene Arshinov <span dir="ltr"><<a href="mailto:earshinov@gmail.com">earshinov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all.<br>
<br>
When several instances of Geany quit in the same time, there is a high<br>
possibility of a conflict. I can reproduce it easily on my machine,<br>
using either trunk or SM version.<br>
<br>
To reproduce: open three instances of geany, "geany", "geany -i" and<br>
another "geany" (absence of file names implies -i automatically in<br>
this case). It would be better to open three different files in<br>
the instances, to distinguish them. Then logout or reboot without<br>
quitting geany manually. On my machine, after I (in case of<br>
trunk) or SM code (in case of SM) restart geany, the default session is<br>
always cleared. Expected behaviour: the default session is managed by<br>
the first of the three instances and contains the files, which<br>
were opened in that instance, after restart.<br></blockquote><div><br>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)<br>
<br>Why is the first necessarily the "master"?  <br>Is this by definition or is there a reason?  <br>What if the first is started with -i? <br> And what happens to configuration changes I make in other instances?<br>
<br>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?<br>
<br>These are questions beyond just the session manager I know, but maybe the answer is/should be the same.<br><br>Cheers<br>Lex<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
I can see two solutions for this problem. The first is an<br>
additional POSIX process-shared semaphore / mutex for Windows to guard<br>
geany.conf. This should eliminate the problem completely. AFAIK, there<br>
are no wrappers for process synchronization primitives in GLib, so I'll<br>
need to write a thin wrapper myself.<br>
<br>
The second option is to change the behaviour of "new instances". If<br>
such an instance (#1) detects a "main instance" (#2) running, it should<br>
not touch geany.conf. Actually, to deal with the described issue, it<br>
is enough to implement this behaviour only when #1 tries to save<br>
geany.conf while quitting.<br>
<br>
The second option is easier to write as it does not require<br>
additional synchronization primitives and it's possible to reuse the<br>
code of socket.c. Actually, I already have this option implemented, to<br>
check whether it indeed solves the problem. But, you see, this<br>
solution can't prevent the race condition completely, in distinction<br>
from the first solution. Moreover, some of you may consider the second<br>
solution "hackish", which is enough to decline it.<br>
<br>
So, the first solution is right, but the second is easy :-) What do you<br>
think?<br>
<br>
Best regards,<br>
Eugene.<br>
_______________________________________________<br>
Geany-devel mailing list<br>
<a href="mailto:Geany-devel@uvena.de">Geany-devel@uvena.de</a><br>
<a href="http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel" target="_blank">http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel</a><br>
</blockquote></div><br>