From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r109890: Do not mark objects from deleted buffers, windows and frames. Date: Wed, 05 Sep 2012 14:24:41 -0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1346869488 12480 80.91.229.3 (5 Sep 2012 18:24:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 5 Sep 2012 18:24:48 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 05 20:24:50 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T9KHR-0005Sz-8z for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 20:24:49 +0200 Original-Received: from localhost ([::1]:52235 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9KHO-0000DY-9v for ged-emacs-devel@m.gmane.org; Wed, 05 Sep 2012 14:24:46 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52261) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9KHL-0000B8-Jq for emacs-devel@gnu.org; Wed, 05 Sep 2012 14:24:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T9KHK-000856-JF for emacs-devel@gnu.org; Wed, 05 Sep 2012 14:24:43 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:61407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T9KHK-00084x-Eh for emacs-devel@gnu.org; Wed, 05 Sep 2012 14:24:42 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxINJ/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLDiYHCxQYDSSIHAW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="197589256" Original-Received: from 69-196-131-73.dsl.teksavvy.com (HELO pastel.home) ([69.196.131.73]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 05 Sep 2012 14:24:41 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 7514B588E8; Wed, 5 Sep 2012 14:24:41 -0400 (EDT) In-Reply-To: (Dmitry Antipov's message of "Wed, 05 Sep 2012 19:34:45 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153066 Archived-At: > Do not mark objects from deleted buffers, windows and frames. I'm not sure this is safe. Such deleted objects are still perfectly live from the memory-allocation point of view, and while some operations on them are disallowed "for ever", there are others that might still be permitted and which may still access internal data. E.g. you might still be able to get (window|frame)-parameters of a deleted (window|frame). IOW, it adds lines of code, makes the invariants more complex (in ways which I'm not sure is currently ensured by the rest of the code) and the benefits aren't obvious at all. I don't think scanning those objects can take a noticeable amount of time, so the only potential issue is holding on to data that can never be used again, in which case I'd much prefer changing kill-buffer/delete-(window|frame) so they set the various fields to NULL/nil. Which is a much safer change. Stefan