GNU bug report logs - #66993
[PATCH] project.el: avoid asking user about project-list-file lock

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Tue, 7 Nov 2023 21:29:02 UTC

Severity: normal

Tags: patch

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #50 received at 66993 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 66993 <at> debbugs.gnu.org
Subject: Re: bug#66993: [PATCH] project.el: avoid asking user about
 project-list-file lock
Date: Wed, 08 Nov 2023 10:41:15 -0500
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Date: Wed, 8 Nov 2023 15:56:11 +0200
>> Cc: sbaugh <at> janestreet.com, 66993 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dmitry <at> gutov.dev>
>> 
>> On 08/11/2023 15:50, Eli Zaretskii wrote:
>> > Why do you need an error when you can use file-locked-p to check up
>> > front that the file is locked?
>> 
>> IIUC the problem comes due to concurrent writes from concurrent writes 
>> from parallel Emacs instances.
>> 
>> Simply checking whether the file is locked before writing, without 
>> trying to obtain the lock, is unlikely to be a reliable solution 
>> (another instance might lock it right after we checked).
>> 
>> Anyway, these writes must be very fast and relatively infrequent. So I'm 
>> surprised that this has came up, personally.
>
> If that's the case, just catch the error and retry, several times,
> perhaps with variable delays.

Perhaps, but it would be nice to do that by catching specifically
file-locked rather than catching all errors.  Which is something which
can't be done right now, other than with the cl-flet approach in my
original approach.




This bug report was last modified 1 year and 268 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.