On 27 February 2010 02:15, Nick Treleaven
<nick.treleaven@btinternet.com> wrote:
On Wed, 24 Feb 2010 12:04:20 +0300
Eugene Arshinov <earshinov@gmail.com> 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