From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75209: 30.0.93; Emacs reader failed to read data in "/home/nlj/.cache/org-persist/gc-lock.eld" Date: Thu, 02 Jan 2025 20:48:42 +0200 Message-ID: <86y0zthx11.fsf@gnu.org> References: <878qrxgg74.fsf@Phoenix> <864j2lnf1j.fsf@gnu.org> <87ldvvhhqo.fsf@localhost> <87frm3elkr.fsf@Phoenix> <878qrvhe0k.fsf@localhost> <86v7uzljc5.fsf@gnu.org> <87ldvug9a3.fsf@localhost> <86ttailoi9.fsf@gnu.org> <87y0ztqg65.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17799"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75209@debbugs.gnu.org, njackson@posteo.net To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 02 19:49:29 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tTQG8-0004Sz-V4 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jan 2025 19:49:29 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTQFr-00081t-Lc; Thu, 02 Jan 2025 13:49:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTQFi-000818-IS for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 13:49:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tTQFi-0002al-6R for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 13:49:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=O1zUGbbQQ9TyAn9xdnefRNQX4fMdPDLkQeWwxJcCShs=; b=AaNE1jVYP2GF9bica22oUdp60XJsvjEb02fWDCJtyjauIqvslkNJ3Czc90SGjdVyFJx8z/zCOgOPHkaCb9Fs2jNzKYyjBv8QfFTFsxeZaSERIIUy+k5cjFU9s9+yS1akoh9UgtV3V7YniwVjI3ixIYUmYXSgMyXcplWB9uSctwEmDtNwWzhCbuZ8sId91Z+T8hyfAcqiJnjx7j7Ac/ufHMTS6v3Gvr7qbk1cRoAuccrYiGN9W8ehj2J839s2UdYmIFhyo92i+mlXB0mm7oyv8CbvP9jhMqNflOmA3flEE4R5RaqRKIsPD7GJgLjY1RjUp1gPlz8DBu1eeXmG/8EDPQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTQFh-0000i2-Oz for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 13:49:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2025 18:49:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75209 X-GNU-PR-Package: emacs Original-Received: via spool by 75209-submit@debbugs.gnu.org id=B75209.17358437372716 (code B ref 75209); Thu, 02 Jan 2025 18:49:01 +0000 Original-Received: (at 75209) by debbugs.gnu.org; 2 Jan 2025 18:48:57 +0000 Original-Received: from localhost ([127.0.0.1]:46651 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTQFd-0000hk-6R for submit@debbugs.gnu.org; Thu, 02 Jan 2025 13:48:57 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59640) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTQFa-0000hW-5K for 75209@debbugs.gnu.org; Thu, 02 Jan 2025 13:48:55 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTQFS-0002ZU-Sq; Thu, 02 Jan 2025 13:48:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=O1zUGbbQQ9TyAn9xdnefRNQX4fMdPDLkQeWwxJcCShs=; b=A5yby2zPozit vO27DaQgVmEQ1kZuf4sRGvP+403u7onqFry7CH5YiZ0APBUyP0UHP8I7QFtdMSuFL8+MoGrFDMfsb 244JzjzYqV4f5v69QM6r0PtkLkzJCKseHYiIfTFd/I+Mg5pQQXc4sSLVO33mg0rVMbX2USzEkAj0q YPRQplEs6QqKWCSIim6cwu6EEmY1lRxHqJo8ow7J3EVGfaeOvcRLeGTVUg6q/teUYemlgEomvzJEe Apkys7WVoPmMpRBkD59Q2ua1b1r3I85sSgFTbIKgFw87NU+BVMqxTfpCYf9m9fA19OZ1HEQLKo2Yc Vl3/KUq3iBw8o3oqo8A6Xg==; In-Reply-To: <87y0ztqg65.fsf@localhost> (message from Ihor Radchenko on Thu, 02 Jan 2025 17:28:02 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298218 Archived-At: > From: Ihor Radchenko > Cc: njackson@posteo.net, 75209@debbugs.gnu.org > Date: Thu, 02 Jan 2025 17:28:02 +0000 > > Eli Zaretskii writes: > > > 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? > > Let me then describe briefly what org-persist does. > > In the nutshell, it is cache manager. > The main cache data consists of: > 1. index describing everything stored in the cache and its expiry > settings > 2. cache data stored in individual files. Each file in the cache is > mentioned in the index file > > >From time to time (before quitting Emacs), org-persist needs to do some > "garbage collection" and remove cache files that are expired or > unreferenced from index to avoid cache growing infinitely. > > The GC process works well, and helps keeping the cache directory > clean. However, there are problems when multiple Emacs processes are > running simultaneously. > > Consider Emacs A loading cache index into memory and doing nothing. > Then, Emacs B also loads the cache index, but adds data to the cache. > If Emacs A is closed while Emacs B is running (and Emacs B not yet > updating cache index on disk), it also performs garbage > collection. However, Emacs A has no knowledge about cache data written > by Emacs B and may "garabge collect" this data. We do not want that. Thanks. I think I still don't have a clear idea of the usage of these caches. Are the caches supposed to be common to all Emacs sessions? E.g., when a cache changes by one session, are other sessions supposed to know about the change? If the cache is for a single session, then why are several session allowed to write to the cache simultaneously? And if the cache is common to all sessions, then perhaps reading the index before writing it should avoid several sessions step on each other's toes? > "gc-lock.eld" keeps track of the running Emacs processes - every Emacs > process regularly write to "gc-lock.eld", putting a record in the form > of (before-init-time . ). If > there are no known recently running Emacs processes (apart from > current), garbage collection process is suppressed to avoid removing > cache data from other Emacsen. One way of rewriting a file atomically is to write the stuff to a temporary file, then rename it to the target name. If Org doesn't already do that, maybe you should try doing that (together with reading the file before updating it)?