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

Lex Trotman elextr at xxxxx
Sun Feb 28 21:21:43 UTC 2010

2010/3/1 Enrico Tröger <enrico.troeger at uvena.de>

> On Fri, 26 Feb 2010 15:15:02 +0000, Nick 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
> >thoughts:
> >
> >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 completely agree here.
> As said in another reply, file locks/semaphores are most pobably
> overkill here.
> Just make the first instance the master (by definition) and this
> instance is the only one which writes the config. All other instances
> may read but must not write.

Just to check my understanding is that -i means run a whole new Geany and
don't create or talk to the socket?

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.

Otherwise the first Geany is effectively ignoring the -i command and is
setting up the socket?

Makes it easy, (for users and code) if run with -i  = don't save config.


> This is the easy implementation but also the most logical to me, more
> logical than 'last instance wins' especially in terms of closing
> multiple instances on system logout where 'last' is quite randomly as
> anyone said in another reply.
> If the master setting works correctly, we don't need to fiddle with
> semaphores, they would be only an additional tool to enforce the master
> instance but IMO it's not worth.
> Regards,
> Enrico
> --
> Get my GPG key from http://www.uvena.de/pub.asc
> _______________________________________________
> Geany-devel mailing list
> Geany-devel at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20100301/549b4520/attachment.html>

More information about the Devel mailing list