[Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf
elextr at xxxxx
Fri Feb 26 22:05:12 UTC 2010
On 27 February 2010 02:15, Nick Treleaven <nick.treleaven at btinternet.com>wrote:
> On Wed, 24 Feb 2010 12:04:20 +0300
> Eugene Arshinov <earshinov at 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.
> > 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?
> Perhaps without clearly answering you, here's my non-technical
> To be easy to implement, perhaps maybe only the first/main instance
> should save settings. We could have a Tools->Save Config menu item
> enabled for the first instance to allow the user to restart other
> instances with the new settings.
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.
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 ;-)
> Project settings should still be saved in all instances. Plugin
> settings should not be saved in new instances, so we would need to
> introduce an API callback signal for save-settings and all plugins
> would need updating.
> Geany-devel mailing list
> Geany-devel at uvena.de
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel