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

[Spencer Baugh <sbaugh@janestreet.com>]

Michael Albinus <michael.albinus@gmx.de> writes:
> Spencer Baugh <sbaugh@janestreet.com> writes:
>
> Hi Spencer,
>
>> If a user has multiple Emacs instances open using one or more of these
>> features, it's fairly easy for both of the Emacs instances to see a
>> new project at the same time.  In that case, they'll both call
>> project--write-project-list at the same time, which will clash and run
>> ask-user-about-lock.  This will happen frequently if the user is often
>> looking at new projects.
>>
>> There's no correct answer the user can give to ask-user-about-lock:
>> either way, one of the Emacs instances will have its project-list-file
>> update lost.  So let's not even bother prompting the user: just do
>> nothing if project-list-file is currently locked.
>
> If you don't care about locking project-list-file, let-bind
> create-lockfiles to nil while writing project-list-file.

Hm, I think that could result in two writes clobbering each other in a
way that creates an invalidly formatted file.  This would happen if
e.g. there were two concurrent write-regions that got interleaved like:

1. write-region(A) starts and writes first half
2. write-region(B) starts and completes
3. write-region(A) writes second half

Then it would be some combination of A and B, which might not be validly
formatted.  From a brief look at the write-region implementation, this
is possible.  (The thing that would make this impossible is if
write-region wrote into a tempfile and then renamed it on top of the
destination.  Instead write-region just writes directly into the file,
opening it with O_TRUNC.)

It's not very likely, but if the lock is conflicting at all and the
project list is large then this will probably happen eventually.