From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Failing to GC killed buffers considered harmful Date: Tue, 31 Mar 2020 17:07:46 +0300 Message-ID: <83tv241utp.fsf@gnu.org> References: <838sjj5jg9.fsf@gnu.org> <83eet93ccb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="53580"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@gmail.com, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Mar 31 16:10:51 2020 Return-path: Envelope-to: ged-emacs-devel@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 1jJHbP-000Dpo-4q for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 16:10:51 +0200 Original-Received: from localhost ([::1]:38678 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJHbO-0000xB-4D for ged-emacs-devel@m.gmane-mx.org; Tue, 31 Mar 2020 10:10:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48026) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jJHYE-0003PK-RB for emacs-devel@gnu.org; Tue, 31 Mar 2020 10:07:35 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38830) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1jJHYE-0008CS-Ex; Tue, 31 Mar 2020 10:07:34 -0400 Original-Received: from [176.228.60.248] (port=4392 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jJHYD-0003Os-Lv; Tue, 31 Mar 2020 10:07:34 -0400 In-Reply-To: (message from Stefan Monnier on Mon, 30 Mar 2020 15:40:31 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246096 Archived-At: > From: Stefan Monnier > Cc: pipcet@gmail.com, dancol@dancol.org, emacs-devel@gnu.org > Date: Mon, 30 Mar 2020 15:40:31 -0400 > > > What are the advantages? > > Simpler code. I'm not sure I see the simplification, certainly not a significant one that would justify the risks. You've replaced one macro with a similar (and subtly different) one which is used in the same way. You've also removed a single variable with a very simple structure and use pattern. I'm not sure I see the gains. On the downside, I see a few possible pitfalls: . How did you test this? In particularly, did it survive the test in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39962#116? . We will be tracking buffers via Vbuffer_alist, from which we remove the killed buffer in kill-buffer much earlier than from all_buffers, and not inside a critical section -- cannot this cause some problems if there's a race in updating Vbuffer_alist? . What about the following comment earlier in this thread: > And yes, you do have to dump killed buffers. If we have a Lisp reference > to a buffer and we can't dump buffers, what do we do? Fail the dump? > Replace the reference with the integer 5? Does this issue no longer bother us? If so, what changed our minds? So I'm not sure why would we want to take the risk of breaking things due to this change, given that the gains are minor at best. Will this allow us to add some useful feature or make some other worthy change that is impossible or impractical/hard without the change?