From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Thu, 29 Mar 2018 08:31:26 -0700 Message-ID: <419cb2c8-0c26-104a-bab5-ba67ad148b88@dancol.org> References: <1775923222.898447.1518559575706@mail.libero.it> <277032065.898859.1518560883271@mail.libero.it> <1901861254.379742.1519646632018@mail.libero.it> <546679939.469612.1522307541367@mail.libero.it> <3b0dd2cd-fd15-c017-7249-7ae2fa567556@dancol.org> <87zi2rqkzi.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1522337388 9171 195.159.176.226 (29 Mar 2018 15:29:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Mar 2018 15:29:48 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 Cc: Angelo Graziosi To: Pip Cet , emacs-devel@gnu.org, rpluim@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 29 17:29:44 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1ZUk-0002F8-9w for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 17:29:42 +0200 Original-Received: from localhost ([::1]:33888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1ZWn-00065n-Ub for ged-emacs-devel@m.gmane.org; Thu, 29 Mar 2018 11:31:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f1ZWc-000640-Qu for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:31:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f1ZWZ-0003HU-I1 for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:31:38 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:53482) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f1ZWZ-0003FU-6F for emacs-devel@gnu.org; Thu, 29 Mar 2018 11:31:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject; bh=Poo/OcwtQnq0abRDejS/NtXSduxGSzfMzgNpiGAvB34=; b=G6YBOtrBoZeWdChvpmHtkLUH2eegL82kKFJMYLNwLJwzgOUSupL0qAfmo59EaPKZs87irNTIR6s1drR929+cgCzg7hnqvvqTjwazCP/6Rm+zUaOXdi/VOCixevePSZFGCwDmXpxtAD0O0zJL3X8693nc0/pOrBAW1YbLS8XEJnbFH7ZkJrAe3rHrpnpCQbcy4gH30wtlYgD3tVQ/gl7TQqRxLgL88qt5gfMK7QXFwnUTF0J+55fBYKZO/V+aZqVQRLA6MSZQJjNhLBnPoaVi3TQnBL7hlDkmP2GXljSKWniF76FY3l7O+PjhsCioZFbG78GVjRq0PwrAfieICzsEzA==; Original-Received: from [172.92.145.124] (helo=[192.168.86.27]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1f1ZWW-00047r-LX; Thu, 29 Mar 2018 08:31:32 -0700 In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:224158 Archived-At: On 03/29/2018 06:35 AM, Pip Cet wrote: > I've just skimmed the diff, and I think the change is a significant > improvement, and will help with my GC experiments even though I'm > probably never going to be able to use the portable dumper. Why not? I eventually want to remove unexec entirely. > Some minor > comments: > > it is not clear to me why some staticpro's are moved to happen after > the initialisation of the variable and some aren't. The code has always been a bit unclear about that; we don't GC that early, so it doesn't really matter- -- but if we did, we'd be saved by nil being all zero these days. > Maybe we should > change staticpro to have a > void staticpro(Lisp_Object *ptr, Lisp_Object initial_value); > signature and save some lines of code? Sometimes the value from .data is perfectly good though, and at that point, the initial_value setting would be a waste. > I don't understand this hunk in sysdep.c: > > @@ -2138,7 +2149,7 @@ init_signals (bool dumping) > #ifdef SIGUSR2 > add_user_signal (SIGUSR2, "sigusr2"); > #endif > - sigaction (SIGABRT, &thread_fatal_action, 0); > + //sigaction (SIGABRT, &thread_fatal_action, 0); > #ifdef SIGPRE > sigaction (SIGPRE, &thread_fatal_action, 0); > #endif Thanks; I'll clean that up. That's left over from the demand paging experiment. > > Similarly, this hunk in pcase.el: > > @@ -63,6 +63,7 @@ > ;; FIXME: Now that macroexpansion is also performed when loading an interpreted > ;; file, this is not a real problem any more. > (defconst pcase--memoize (make-hash-table :weakness 'key :test 'eq)) > +;; (defconst pcase--memoize (make-hash-table :test 'eq)) > ;; (defconst pcase--memoize-1 (make-hash-table :test 'eq)) > ;; (defconst pcase--memoize-2 (make-hash-table :weakness 'key :test 'equal)) > Thanks for catching that. > Are those two intentional? > > I would vaguely prefer if "pdumper" names were limited to the actual > pdumper implementation, and "dumper" names were used instead in code > that does not depend on the implementation of the dumper. So we'd have > dumper_object_p(), defined to false if there's no dumper, and > pdumper_object_p otherwise. I'd rather not do a big renaming at this point. Nothing stops someone doing cleanup work post-merge if sufficiently motivated. > Apart from that, there appear to be no disadvantages for people who > prefer to continue using unexec. Is that correct? That's correct.