<br><br><div class="gmail_quote">On 27 February 2010 02:15, Nick Treleaven <span dir="ltr"><<a href="mailto:nick.treleaven@btinternet.com">nick.treleaven@btinternet.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;">
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 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>
><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>
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></blockquote><div><br>I havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections.  If so then I assume all Geany commands without the -i  will be the same instance, and this is the one that should be able to save.  There needs to be a visual distinction of instances that can & can't save.  I wouldn't worry about the other -i instances being able to get settings until the main closes.<br>
<br>As I implied in my comment on another message, my use case was to have the filemanager programmed to start a new instance if I double click to look at a file so it doesn't interfere with my "main" instance.  I know the socket system was intended to cause exactly the opposite but I've always been a contrary sorta person ;-)<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;">
<br>
Project settings should still be saved in all instances. Plugin<br>
settings should not be saved in new instances, so we would need to<br>
introduce an API callback signal for save-settings and all plugins<br>
would need updating.<br>
<br>
Regards,<br>
<font color="#888888">Nick<br>
</font><div><div></div><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br>