[Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf

[Randy Kramer]

I haven't paid careful attention to this thread, but on several projects 
I've worked on, we've adopted a "last to save, wins" philosophy for 
situations (somewhat) similar to this.

I've learned to deal with that in several applications including nedit, 
and it seems to be a reasonable approach, requiring, iiuc, no work.

Randy Kramer

On Friday 26 February 2010 10:15:02 am Nick Treleaven wrote:
> On Wed, 24 Feb 2010 12:04:20 +0300
> Eugene Arshinov <earshinov at gmail.com> wrote:
> > 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.