From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.bugs Subject: bug#49261: 28.0.50; File Locking Breaks Presumptuous Toolchains Date: Wed, 07 Jul 2021 20:58:29 +0200 Message-ID: <878s2i3q96.fsf@gnus.org> References: <87o8bn7bie.fsf@gnus.org> <87zgv6vuon.fsf@gmx.de> <837di9lwbm.fsf@gnu.org> <87a6n5vuu4.fsf@gnus.org> <8735sqnmei.fsf@gnus.org> <834kd6f1dw.fsf@gnu.org> <87h7h6m1jh.fsf@gnus.org> <83zguydkyz.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="25047"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: michael.albinus@gmx.de, ncaprisunfan@gmail.com, 49261@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jul 07 20:59:18 2021 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 1m1ClS-0006Nv-3g for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Jul 2021 20:59:18 +0200 Original-Received: from localhost ([::1]:44976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1m1ClR-0004tI-5G for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 07 Jul 2021 14:59:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38310) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1m1ClC-0004ps-7m for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 14:59:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:41954) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1m1ClC-0002wB-0N for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 14:59:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1m1ClC-0007e6-0c for bug-gnu-emacs@gnu.org; Wed, 07 Jul 2021 14:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Jul 2021 18:59:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 49261 X-GNU-PR-Package: emacs Original-Received: via spool by 49261-submit@debbugs.gnu.org id=B49261.162568432129351 (code B ref 49261); Wed, 07 Jul 2021 18:59:01 +0000 Original-Received: (at 49261) by debbugs.gnu.org; 7 Jul 2021 18:58:41 +0000 Original-Received: from localhost ([127.0.0.1]:53498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ckq-0007dK-Pn for submit@debbugs.gnu.org; Wed, 07 Jul 2021 14:58:41 -0400 Original-Received: from quimby.gnus.org ([95.216.78.240]:54598) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m1Ckp-0007d2-Iu for 49261@debbugs.gnu.org; Wed, 07 Jul 2021 14:58:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=MZFNT05YYat8ZvefE/nBRI7NLKtq3cXR2DTAloZ6idY=; b=OkBPSpWfrBKAcyNvlPfNH0i7h0 GEvvIDThKORoUPybVFg6XMhCzXnCiooX+kGYfmE1GRmtytGFc4NTyPs+UgQdDbQD83pFK0yOa0HNp 9P2WkL/RZ+JibScWyFi02yZ/mOo1VrSbSANzuj9VtmErVQ52dnKseVHflPPL/9e2OXAk=; Original-Received: from cm-84.212.220.105.getinternet.no ([84.212.220.105] helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1m1Ckf-0000nF-QI; Wed, 07 Jul 2021 20:58:32 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAElBMVEUHBwcoLixKVlRR dISqraj////Hgq6aAAAAAWJLR0QF+G/pxwAAAAd0SU1FB+UHBxIxKEngHG4AAAGkSURBVDjLrZNh koMgDIWJ7gFI5AASPUAVDlAl9z/TBkTFzu6/OtOOzTckeY9XY777wJf71a72jxoC0YA0ftbD0OFr sJ4+EXVgFzLjMFJbnkzf8zRNvIYHgGg7YPSIRMvymGBNRx5HYw3ZDwBoDcJzgjEh00lWRP+o4yyJ Z1lUCyLWNbVnL+UpAtBWUzlKEtGv9XTldBtmrUfZrrbNVqDgXd9tJQeOSV61PoPF+4h2q8A7MA2g +WxFC+B4kyHKfk80/iIuSWrv7FrMbSIN6Oy54SxDA0x3bxX2FjTrpvgfcBfomBuw9xfomW+33A7p /PWI8ryZeGYAi4oqUatureKwEFfBS/NQvJk2rWfgbLmPt4E8ciWbw6Wln3krQE1nvfIAoOHNoJul 3K4WGXUieCU5QV25IZhsdQit6isgxZ0UH/nQnQytuacB+ZE4GoJDmIZKc81ZUvQSvSYWkbMC1Bdf LInbxPTqd40oHygnQj9hhyji/J4zujeJ9hbJSSLWOK55n9PLfHKQmDgPDSEwD5frLiJUX1UD+3CG zVtVcPwr9JQtzX4BceY4qJAP7wIAAAAQZVhJZklJKgAIAAAAAAAAAAAAAACcPLkoAAAAJXRFWHRk YXRlOmNyZWF0ZQAyMDIxLTA3LTA3VDE4OjQ5OjM5KzAwOjAwPKRZbwAAACV0RVh0ZGF0ZTptb2Rp ZnkAMjAyMS0wNy0wN1QxODo0OTozOSswMDowME354dMAAAAASUVORK5CYII= X-Now-Playing: Tuxedomoon's _Live At The Palms (1978)_: "Cell Life" In-Reply-To: <83zguydkyz.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 07 Jul 2021 21:42:28 +0300") 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" Xref: news.gmane.io gmane.emacs.bugs:209616 Archived-At: Eli Zaretskii writes: > Even if it currently works, it's unsafe, IMO, to not have any > protection there. No one will remember that we rely on this not being > called early enough. Right. My reasoning was that it seemed unlikely to be a problem here, since the same function also (possibly) calls the Lisp functions userlock--ask-user-about-supersession-threat and ask-user-about-lock. But those are only called in some cases, so we're calling out to Lisp more now than before, and that may indeed be a problem. I can add a check to whether the Lisp function is defined before calling (and then not do locking if it isn't) to be more defensive here? > My point is that this simplicity comes at a price. We've been > consistently moving code from C primitives to Lisp, and by doing that > significantly increase the consing during even the simplest editing > operations. All this consing adds up, with the result that Emacs > nowadays produces much more garbage, which then triggers frequent GC > cycles, which slow down Emacs. It's a small wonder we see so many > people out there raising the GC threshold to dangerous levels. > > So I'm asking whether the simplicity justifies the costs, here and > elsewhere. I agree with you 100% that it's important to take this into consideration when moving things from C to Lisp. In this particular case, I think the cost is justified, because this isn't a function that's called in a loop, and the other things it does (calling Fverify_visited_file_modtime and Ffile_exists_p, and actually creating the lock file) totally swamps any extra string consing, I think. (That is, it won't take measurably longer.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no