From: Paul Mackerras <paulus@samba.org>
To: Max Kirillov <max@max630.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v4 2/2] gitk: synchronize config write
Date: Mon, 2 Mar 2015 11:10:51 +1100 [thread overview]
Message-ID: <20150302001050.GC24862@iris.ozlabs.ibm.com> (raw)
In-Reply-To: <1415571602-5858-3-git-send-email-max@max630.net>
On Mon, Nov 10, 2014 at 12:20:02AM +0200, Max Kirillov wrote:
> If several gitk instances are closed simultaneously, safestuff procedure
> can run at the same time, resulting in a conflict which may cause losing
> of some of the instance's changes, failing the saving operation or even
> corrupting the configuration file. This can happen, for example, at user
> session closing, or at group closing of all instances of an application
> which is possible in some desktop environments.
>
> To avoid this, make sure that only one saving operation is in progress.
> It is guarded by existance of $config_file_tmp file. Both creating the
> file and moving it to $config_file are atomic operations, so it should
> be reliable.
>
> Reading does not need to be syncronized, because moving is atomic
> operation, and the $config_file always refers to full and correct file.
> But, if there is a stale $config_file_tmp file, report it at gitk start.
> If such file is detected at saving, just abort the saving, because this
> is how gitk used to handle errors while saving.
>
> Signed-off-by: Max Kirillov <max@max630.net>
The idea looks good; I have a couple of comments on the patch. First,
50 tries over 5 seconds seems a bit excessive to me, wouldn't (say) 20
tries be enough? Is the 50 the result of some analysis?
> + error_popup "Probably there is stale $config_file_tmp file; config saving is going to fail. Check if it is being used by any existing gitk process and remove it otherwise"
I would word this as "There appears to be a stale $config_file_tmp
file, which will prevent gitk from saving its configuration on exit.
Please remove it if it is not being used by any existing gitk
process."
> @@ -2811,11 +2824,16 @@ proc savestuff {w} {
>
> if {$stuffsaved} return
> if {![winfo viewable .]} return
> + set remove_tmp 0
> catch {
> - if {[file exists $config_file_tmp]} {
> - file delete -force $config_file_tmp
> + set try_count 0
> + while {[catch {set f [open $config_file_tmp {WRONLY CREAT EXCL}]}]} {
> + if {[incr try_count] > 50} {
> + error "Unable to write config file: $config_file_tmp exists"
> + }
> + after 100
> }
> - set f [open $config_file_tmp w]
> + set remove_tmp 1
> if {$::tcl_platform(platform) eq {windows}} {
> file attributes $config_file_tmp -hidden true
> }
> @@ -2878,6 +2896,14 @@ proc savestuff {w} {
> puts $f "}"
> close $f
> file rename -force $config_file_tmp $config_file
> + set remove_tmp 0
> + return ""
> + } err
> + if {$err ne ""} {
> + puts "Error saving config: $err"
I would suggest checking the return from the catch statement, like
this:
if {[catch {
...
file rename -force $config_file_tmp $config_file
} err]} {
puts "Error saving config: $err"
if {$remove_tmp} {
file delete -force $config_file_tmp
}
}
rather than doing a return inside the catch.
Paul.
next prev parent reply other threads:[~2015-03-02 0:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-09 22:20 [PATCH v4 0/2] gitk: save only changed configuration on exit Max Kirillov
2014-11-09 22:20 ` [PATCH v4 1/2] gitk: write only changed configuration variables Max Kirillov
2015-03-01 23:47 ` Paul Mackerras
2015-03-02 20:34 ` Max Kirillov
2014-11-09 22:20 ` [PATCH v4 2/2] gitk: synchronize config write Max Kirillov
2015-03-02 0:10 ` Paul Mackerras [this message]
2015-03-02 20:43 ` Max Kirillov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150302001050.GC24862@iris.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=git@vger.kernel.org \
--cc=max@max630.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.