From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 14:36:08 -0400 Message-ID: <20140625183608.GX179@brightrain.aerifal.cx> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <20140625180823.GV179@brightrain.aerifal.cx> <53AB153E.4080905@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1403721415 28717 80.91.229.3 (25 Jun 2014 18:36:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 18:36:55 +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 Jun 25 20:36:48 2014 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 1Wzs3o-00066E-3T for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 20:36:44 +0200 Original-Received: from localhost ([::1]:40406 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzs3n-0000eo-KR for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 14:36:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50647) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzs3U-0000cr-4U for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:36:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wzs3M-0003tY-K8 for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:36:24 -0400 Original-Received: from 216-12-86-13.cv.mvl.ntelos.net ([216.12.86.13]:44423 helo=brightrain.aerifal.cx) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzs3M-0003sN-61 for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:36:16 -0400 Original-Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1Wzs3E-0002ot-00; Wed, 25 Jun 2014 18:36:08 +0000 Content-Disposition: inline In-Reply-To: <53AB153E.4080905@yandex.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 216.12.86.13 X-Mailman-Approved-At: Wed, 25 Jun 2014 14:36:41 -0400 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:172717 Archived-At: On Wed, Jun 25, 2014 at 10:30:22PM +0400, Dmitry Antipov wrote: > On 06/25/2014 10:08 PM, Rich Felker wrote: > > >Are there such objects that need to be preserved across dumping? > > I don't know, and the worst thing is that we can't control over this. Sure you can. If the lisp code doesn't reference such objects then their existence of nonexistence is irrelevant to the new emacs invocation after dumping. > With my debug build, 'ldd src/temacs | wc -l' shows 112 external > libraries. What if just one of these libraries uses malloc() to allocate > an internal object in __attribute__((constructor)) function? If these libraries are shared libraries, all of that state will be lost during dumping and reinitialized when the library is loaded again at runtime. As long as we're using the existing dumper system, where the whole data segment gets written out to a new executable file, I agree there's such a problem for static linking. But if emacs switched to the new system I proposed, where ONLY the lisp state were dumped to a static array, then none of these libraries' state could be saved at all, and thus there would be no danger. Rich