2010/3/1 Enrico Tröger <[email protected]> > On Fri, 26 Feb 2010 15:15:02 +0000, Nick wrote: > > >On Wed, 24 Feb 2010 12:04:20 +0300 > >Eugene Arshinov <[email protected]> wrote: > > > >> 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? > > > >Perhaps without clearly answering you, here's my non-technical > >thoughts: > > > >To be easy to implement, perhaps maybe only the first/main instance > >should save settings. We could have a Tools->Save Config menu item > >enabled for the first instance to allow the user to restart other > >instances with the new settings. > > I completely agree here. > As said in another reply, file locks/semaphores are most pobably > overkill here. > Just make the first instance the master (by definition) and this > instance is the only one which writes the config. All other instances > may read but must not write. >
Just to check my understanding is that -i means run a whole new Geany and don't create or talk to the socket? If so, can I suggest its the first instance started WITHOUT -i that becomes the master, ie the one that sets up the socket. As I understand it, thats the one that all files opened by Geany run without -i will show in. Otherwise the first Geany is effectively ignoring the -i command and is setting up the socket? Makes it easy, (for users and code) if run with -i = don't save config. Cheers Lex > This is the easy implementation but also the most logical to me, more > logical than 'last instance wins' especially in terms of closing > multiple instances on system logout where 'last' is quite randomly as > anyone said in another reply. > If the master setting works correctly, we don't need to fiddle with > semaphores, they would be only an additional tool to enforce the master > instance but IMO it's not worth. > > > Regards, > Enrico > > -- > Get my GPG key from http://www.uvena.de/pub.asc > > _______________________________________________ > Geany-devel mailing list > [email protected] > http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel > >
_______________________________________________ Geany-devel mailing list [email protected] http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
