[Geany-devel] multiple instance save-settings - Re: Race condition when saving geany.conf

[Enrico Tröger]

On Mon, 1 Mar 2010 08:21:43 +1100, Lex wrote:

>2010/3/1 Enrico Tröger <enrico.troeger at uvena.de>
>
>> On Fri, 26 Feb 2010 15:15:02 +0000, Nick wrote:
>>
>> >On Wed, 24 Feb 2010 12:04:20 +0300
>> >Eugene Arshinov <earshinov at 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 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.

Sounds useful.
I didn't check the code but IIRC -i do ignore the socket part if there
is one. I'm not exactly sure whether it does or does not create a new
socket if there is no running instance. Ideally, it should really
ignore all socket stuff and don't save settings. This would be what you
suggest and what would be most consistent, I think.

Regards,
Enrico

-- 
Get my GPG key from http://www.uvena.de/pub.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.geany.org/pipermail/devel/attachments/20100307/fe244cf6/attachment.pgp>