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 <dma...@googlemail.com> http://dominichopf.de/ Key Fingerprint: A7DF C4FC 07AE 4DDC 5CA0 BD93 AAB0 6019 CA7D 868D
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel