<br><br><div class="gmail_quote">2010/3/1 Enrico Tröger <span dir="ltr"><<a href="mailto:enrico.troeger@uvena.de">enrico.troeger@uvena.de</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On Fri, 26 Feb 2010 15:15:02 +0000, Nick wrote:<br>
<br>
>On Wed, 24 Feb 2010 12:04:20 +0300<br>
>Eugene Arshinov <<a href="mailto:earshinov@gmail.com">earshinov@gmail.com</a>> wrote:<br>
><br>
>> Hi all.<br>
>><br>
>> When several instances of Geany quit in the same time, there is a<br>
>> high possibility of a conflict. I can reproduce it easily on my<br>
>> machine, 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<br>
>> is always cleared. Expected behaviour: the default session is<br>
>> managed by the first of the three instances and contains the files,<br>
>> which were opened in that instance, after restart.<br>
>><br>
>> I can see two solutions for this problem. The first is an<br>
>> additional POSIX process-shared semaphore / mutex for Windows to<br>
>> guard geany.conf. This should eliminate the problem completely.<br>
>> AFAIK, there are no wrappers for process synchronization primitives<br>
>> in GLib, so I'll 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<br>
>> should not touch geany.conf. Actually, to deal with the described<br>
>> issue, it is enough to implement this behaviour only when #1 tries<br>
>> to save 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,<br>
>> to 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<br>
>> second solution "hackish", which is enough to decline it.<br>
>><br>
>> So, the first solution is right, but the second is easy :-) What do<br>
>> you think?<br>
><br>
>Perhaps without clearly answering you, here's my non-technical<br>
>thoughts:<br>
><br>
>To be easy to implement, perhaps maybe only the first/main instance<br>
>should save settings. We could have a Tools->Save Config menu item<br>
>enabled for the first instance to allow the user to restart other<br>
>instances with the new settings.<br>
<br>
</div></div>I completely agree here.<br>
As said in another reply, file locks/semaphores are most pobably<br>
overkill here.<br>
Just make the first instance the master (by definition) and this<br>
instance is the only one which writes the config. All other instances<br>
may read but must not write.<br></blockquote><div><br>Just to check my understanding is that -i means run a whole new Geany and don't create or talk to the socket?<br>
<br>
If so, can I suggest its the first instance started WITHOUT -i that becomes the master, ie the one that sets up the socket.  As I understand it, thats the one that all files opened by Geany run without -i will show in.<br>
<br>Otherwise the first Geany is effectively ignoring the -i command and is setting up the socket?<br><br>Makes it easy, (for users and code) if run with -i  = don't save config.<br><br>Cheers<br>Lex<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

This is the easy implementation but also the most logical to me, more<br>
logical than 'last instance wins' especially in terms of closing<br>
multiple instances on system logout where 'last' is quite randomly as<br>
anyone said in another reply.<br>
If the master setting works correctly, we don't need to fiddle with<br>
semaphores, they would be only an additional tool to enforce the master<br>
instance but IMO it's not worth.<br>
<br>
<br>
Regards,<br>
Enrico<br>
<font color="#888888"><br>
--<br>
Get my GPG key from <a href="http://www.uvena.de/pub.asc" target="_blank">http://www.uvena.de/pub.asc</a><br>
</font><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>
<br></blockquote></div><br>