On Fri, 26 Feb 2010 15:15:02 +0000, Nick 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.