[Geany-devel] Race condition when saving geany.conf

Dominic Hopf dmaphy at xxxxx
Sat Feb 27 16:49:06 UTC 2010


Am Mittwoch, den 24.02.2010, 12:04 +0300 schrieb Eugene Arshinov:
> 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?

There always are elegant solutions to solve a problem and maybe
solutions which are not that elegant but would work too. If I understood
you right, the first one would be the one more elegant?

I'd always prefer an elegant solution over one which is not that
elegant. :)

Regards,
Dominic

-- 
Dominic Hopf <dmaphy at googlemail.com>

http://dominichopf.de/

Key Fingerprint:
A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
URL: <http://lists.geany.org/pipermail/devel/attachments/20100227/638632fe/attachment.pgp>


More information about the Devel mailing list