From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko 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 17:28:02 +0000 Message-ID: <87y0ztqg65.fsf@localhost> 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> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36747"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75209@debbugs.gnu.org, njackson@posteo.net To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 02 18:26:35 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 1tTOxu-0009RI-Na for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Jan 2025 18:26:35 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTOxT-0004YW-Tb; Thu, 02 Jan 2025 12:26:08 -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 1tTOxP-0004Xu-2b for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 12:26: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 1tTOxO-0006j2-Qa for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 12:26:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=GFdDvin1CPotivFNybS51Q2HwLEiPjsLsXytGbIpzRQ=; b=gSZSlazkNbzQQu0NIduywMVtWJ5sVmcFVx4hZ7k6bffQ1wp2ejgl8HbXK5aO4I0USY8t+4DeRpW8qAbFwN4aLiQapgOKjYZZKGzvp1rPX/CLfOkz6EYFN/6F22kvJJWG5WNioqtcUivOJYOysvaWlTgs81wVuZ9jj/SSkRoaQTeCFoArLYWc3zg/OctkV4L1NN3pw4ccWR7iGvTSoZ8fmoCJ0MSP130Kr6fhBChBCbLBJHVCBabl+XHEPnpCwSFuomnHuH0m5qbTrTGbGKudTM69kbxfUQtG/nNOExGEZJYPuD3SURqKHdMPq+LFSOXvlrBSGV0Dmm40gVk2slHQZg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTOxO-0004g4-Ku for bug-gnu-emacs@gnu.org; Thu, 02 Jan 2025 12:26:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Jan 2025 17:26:02 +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.173583875417938 (code B ref 75209); Thu, 02 Jan 2025 17:26:02 +0000 Original-Received: (at 75209) by debbugs.gnu.org; 2 Jan 2025 17:25:54 +0000 Original-Received: from localhost ([127.0.0.1]:46440 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTOxF-0004fF-DT for submit@debbugs.gnu.org; Thu, 02 Jan 2025 12:25:53 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:34779) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTOxD-0004ew-9J for 75209@debbugs.gnu.org; Thu, 02 Jan 2025 12:25:51 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 6FCDA240101 for <75209@debbugs.gnu.org>; Thu, 2 Jan 2025 18:25:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1735838743; bh=9LydcE/Sm7dbxczR/mTGONnicJ96HHzMExiosCoisCg=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type: From; b=nsqC/P2Un+Y0hsulXDNAWmDCZnlyVuMaH/AInmzFPhjLTnVoN8zCaccu5+kUoHjdm F8iL914FvwRQl2A86lZosa+spHw7RrvrXvVNuallmxpB4jRcS92N5CilhsLqqSrVOq D7tYmlnTIxNqlCY7nObvUQ5A5txjww19TVIJhi43EDL4qKuLfK9Yx7zlX9K+yxIec+ 5kxlijE+NapQcmQjAzKLkTU3578q+a8s7p6reGu8Ib6X6HvhBYwuT4VGbjD6vp1HvH YWJ5pMXFCXmlTXb5vIsP64T8T+3WrCfJ+JDqtyU3pjg5uP1axMt2N5nCf7d1Hw9pwW yY6aw4PcVT4tw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4YPDBG5DnTz9rxL; Thu, 2 Jan 2025 18:25:42 +0100 (CET) In-Reply-To: <86ttailoi9.fsf@gnu.org> 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:298201 Archived-At: Eli Zaretskii writes: >> 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? 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. "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. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at . Support Org development at , or support my work at