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