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: Dynamic loading progress Date: Sun, 23 Aug 2015 18:26:51 -0400 Message-ID: References: <54E0FF93.2000104@dancol.org> <833865vp4d.fsf@gnu.org> <54E2355A.90@87.69.4.28> <83vbj1u020.fsf@gnu.org> <54E24CA4.9020601@dancol.org> <83h9uk7ddb.fsf@gnu.org> <54E382A5.5030408@dancol.org> <54F789B2.6030105@dancol.org> <87egnel6ac.fsf@lifelogs.com> <87vbgpk1po.fsf@lifelogs.com> <85mw20gmeo.fsf@stephe-leake.org> <878u97nyjn.fsf@lifelogs.com> <86d1yirnqw.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1440368843 11913 80.91.229.3 (23 Aug 2015 22:27:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Aug 2015 22:27:23 +0000 (UTC) Cc: Daniel Colascione , Stephen Leake , Emacs development discussions To: =?windows-1252?Q?Aur=E9lien?= Aptel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 24 00:27:10 2015 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 1ZTdjF-0004JM-PQ for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2015 00:27:05 +0200 Original-Received: from localhost ([::1]:42826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTdjE-000126-Pu for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2015 18:27:04 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60824) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTdj7-0000zH-RX for emacs-devel@gnu.org; Sun, 23 Aug 2015 18:26:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTdj2-0005bP-RJ for emacs-devel@gnu.org; Sun, 23 Aug 2015 18:26:57 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:41368) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTdj2-0005bI-NO for emacs-devel@gnu.org; Sun, 23 Aug 2015 18:26:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CtCwA731xV/5P+d0tcgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSSINwjPIwEBAQcCAR+LOoUFB4QtAQSzP4FFI4Fmgi4igngBAQE X-IPAS-Result: A0CtCwA731xV/5P+d0tcgxCEAsEMCYdLBAICgTw5FAEBAQEBAQGBCkEFg10BAQMBViMFCws0EhQYDSSINwjPIwEBAQcCAR+LOoUFB4QtAQSzP4FFI4Fmgi4igngBAQE X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="161135556" Original-Received: from 75-119-254-147.dsl.teksavvy.com (HELO fmsmemgm.homelinux.net) ([75.119.254.147]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Aug 2015 18:26:52 -0400 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id D4848AE068; Sun, 23 Aug 2015 18:26:51 -0400 (EDT) In-Reply-To: (=?windows-1252?Q?=22Aur=E9lien?= Aptel"'s message of "Sun, 23 Aug 2015 21:12:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:189088 Archived-At: > - Local values which are created/can-be-freed inside the module function. > > a = make_string("foo") > b = make_string("bar") > len = funcall(eval, 1, [length_sym, b]) > // a (and b?) might be invalid now if the GC was triggered inside > the funcall call. > > In the core Emacs code, we have the GCPRO macro to deal with that use-case. GCPRO is only needed if we don't use conservative stack scanning. Conservative stack scanning is used by 99.9% of Emacs builds (so much so that there are always latent bugs in the GCPRO code because it sees very little testing), so I think it's perfectly acceptable to ignore the remaining 0.1%. IOW we don't need to worry about local Lisp_Object values: they'll be found by the conservative stack scanner. > - Values created and reused between 2 module calls. > > emacs_value global_a; > > module_func_A() > global_a = make_string("a") > > module_func_B(): > // global_a might be invalid now if the GC was triggered > between func_A and func_B > return global_a > > In the core Emacs code, global_a is usually a defvar. We just need to export the equivalent of "staticpro" (ideally, this should keep track of which module called it, so that we can automatically "unpro"tect those vars when/if the module is unloaded). > Daniel was talking about tables mapping emacs_value to Lisp_Object, I don't want to have to convert between emacs_value and Lisp_Object, they should be one and the same. Stefan