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

[Enrico Tröger]

On Sun, 28 Feb 2010 14:20:08 +0100, Enrico wrote:

>On Sat, 27 Feb 2010 17:49:06 +0100, Dominic wrote:
>
>>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. :)
>
>IMO file locks/metaphors are clearly overkill here and are probably

s/metaphors/semaphores/


:)

Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20100228/0b5c8195/attachment.pgp>