From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 29 Nov 2016 20:40:50 +0200 Message-ID: <834m2qrux9.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <721b8fb1-5672-778e-b68f-a68b53308f55@cs.ucla.edu> <83vav7xs1p.fsf@gnu.org> <83twarxq6f.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480444925 7179 195.159.176.226 (29 Nov 2016 18:42:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 29 Nov 2016 18:42:05 +0000 (UTC) Cc: eggert@cs.ucla.edu, dancol@dancol.org, emacs-devel@gnu.org To: John Wiegley Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 29 19:42:00 2016 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 1cBnLq-00017R-Qu for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 19:41:58 +0100 Original-Received: from localhost ([::1]:38748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnLu-00068A-LA for ged-emacs-devel@m.gmane.org; Tue, 29 Nov 2016 13:42:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnKq-0005uw-MD for emacs-devel@gnu.org; Tue, 29 Nov 2016 13:41:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBnKm-0000zJ-Fn for emacs-devel@gnu.org; Tue, 29 Nov 2016 13:40:56 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38684) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBnKm-0000z1-Bz; Tue, 29 Nov 2016 13:40:52 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1146 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cBnKl-0000VP-2j; Tue, 29 Nov 2016 13:40:51 -0500 In-reply-to: (message from John Wiegley on Mon, 28 Nov 2016 14:18:58 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:209748 Archived-At: > From: John Wiegley > Cc: eggert@cs.ucla.edu, dancol@dancol.org, emacs-devel@gnu.org > Date: Mon, 28 Nov 2016 14:18:58 -0800 > > > Accepting this patch means we believe in this direction, consider it a > > perspective one, enough so that we are willing to invest a non-trivial > > amount of energy into making it happen, fix the fallout, debug the results, > > etc. We are talking about at least one major release, maybe more, and > > definitely several minor releases. IOW, we are talking several years. I > > don't think we should gamble with such high stakes, not unless we sure we > > want to go there, because this is the best alternative of [...] > > If I didn't know you were talking about pdumper vs. unexec here, I'd swear > this above paragraph was expressing my own concerns about merging Tromey's > concurrency branch. Superficially, perhaps. But as soon as you look at the details, there are two important differences. First, the only piece of code in the concurrency patch that is not entirely trivial is a 60-line function (30% of whose line count is comments and ifdef's). That's all there is to understand there. The rest is extremely simple, almost trivial: functions that directly map into the corresponding system threads APIs, or 2-liners for creation, checking, and otherwise simple management of the few new object types. By contrast, the proposed patch, even in its initial version, weighs in at 3200 lines in its core part, and almost none of it is trivial or simple. What's more, it comes with the need to make important and non-trivial decisions wrt which objects and data structures need to be dumped, and how, something that requires intimate knowledge of the internals and their use patterns, both at dump time and in interactive sessions. These decisions will need to be revisited when the related objects are added or modified, which is the part that averts me the most, because it means extending the Lisp interpreter, which is already not easy, will have become even harder. The other important difference is that threads are an opt-in feature: if you don't start any threads, Emacs with threads still works as it did before, and you can just ignore anything related to threads. IOW, threads are a feature we offer to Lisp programs that want to use it. By contrast, dumping code is a central and mandatory part of building Emacs and of its startup process. It cannot be ignored or made optional.