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

[Enrico Tröger]

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
hard to realise portable (maybe I'm wrong here, I didn't work much
with those so far).

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/fc70a8ed/attachment.pgp>