bug#75209: 30.0.93; Emacs reader failed to read data in "/home/nlj/.cache/org-persist/gc-lock.eld"

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: njackson@posteo.net, 75209@debbugs.gnu.org
> Date: Wed, 01 Jan 2025 09:42:28 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Another possible scenario is two Org instances writing to the same file
> >> at the same time.
> >> If it is what is happening in your case, your problem may be similar to 
> >> https://list.orgmode.org/orgmode/CAMJKaZxA_VmLdFP_u1rNiF2s0X2kVivjT31jEM_r3BYCHri1PQ@mail.gmail.com/
> >
> > Can't Org prevent more than one session writing to this file?  We have
> > file locks which can be used here, I think.
> 
> That's exactly the idea I am trying in the linked thread to address the
> issue.
> 
> It is not the biggest problem there though. The problem is when there is
> a race between Emacs processes writing to the same file one after
> another (without any locking). Contents of the file may then become
> unexpected compared to other Emacs session.

Is the gc-lock.eld file supposed to be a singleton across all the
Emacs sessions?  Earlier you said:

> gc-lock.eld is a file used to flag that cache dir is being worked
> on by multiple emacs instances. GC here refers to
> garbage-collecting cache data.

Can you tell more about the purpose and use of this file?  What is
written to it, and how is it supposed to be used after being written?
And what bad things happen when the Lisp readers errors out because it
is unable to read the data for some reason?

I'm asking because I'd like to think about, and then suggest, some
suitable solutions, but I don't want to suggest nonsensical ones.

Thanks.