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
pgpm6b9Bh53UZ.pgp
Description: PGP signature
_______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
