On 27 February 2010 02:15, Nick Treleaven <[email protected]>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 havn't looked in detail at what the -i option does but I assume it doesn't use or accept socket connections. If so then I assume all Geany commands without the -i will be the same instance, and this is the one that should be able to save. There needs to be a visual distinction of instances that can & can't save. I wouldn't worry about the other -i instances being able to get settings until the main closes. As I implied in my comment on another message, my use case was to have the filemanager programmed to start a new instance if I double click to look at a file so it doesn't interfere with my "main" instance. I know the socket system was intended to cause exactly the opposite but I've always been a contrary sorta person ;-) Cheers Lex > > Project settings should still be saved in all instances. Plugin > settings should not be saved in new instances, so we would need to > introduce an API callback signal for save-settings and all plugins > would need updating. > > Regards, > Nick > _______________________________________________ > 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
