From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 24 Aug 2015 00:45:41 +0200 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; charset=UTF-8 X-Trace: ger.gmane.org 1440369983 27493 80.91.229.3 (23 Aug 2015 22:46:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 23 Aug 2015 22:46:23 +0000 (UTC) Cc: Daniel Colascione , Stephen Leake , Emacs development discussions To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 24 00:46:21 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 1ZTe1t-0007a8-6W for ged-emacs-devel@m.gmane.org; Mon, 24 Aug 2015 00:46:21 +0200 Original-Received: from localhost ([::1]:48039 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTe1s-00023K-Fq for ged-emacs-devel@m.gmane.org; Sun, 23 Aug 2015 18:46:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35998) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTe1H-0001x7-RQ for emacs-devel@gnu.org; Sun, 23 Aug 2015 18:45:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZTe1G-0006wi-Ly for emacs-devel@gnu.org; Sun, 23 Aug 2015 18:45:43 -0400 Original-Received: from mail-ig0-x236.google.com ([2607:f8b0:4001:c05::236]:38737) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZTe1F-0006uI-S3 for emacs-devel@gnu.org; Sun, 23 Aug 2015 18:45:41 -0400 Original-Received: by igfj19 with SMTP id j19so44799867igf.1 for ; Sun, 23 Aug 2015 15:45:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6N90azY0cZWRrAq47IDM6+4SYhCeaZzcLZV7LVsPcrA=; b=0xuyUt+//OxE2LMo9UVNCRTgE6CdPZOLD7NLf89FqqDAbWIAxWjQPBNvmPGp9NRFJD zuKrzI1gqfyY7bIqp74nDNoIiQMB/vgTxzSWpSSKUcCZBokw9bjVXz0uj9kPAJevXSPX edLB3w/cosTDPNXTkzRvGYxMNOkqbXxVmbhUNnxiYWofXMJd/aHWBZtfsqRE9cjZtaEU lU5/Cf7v2bgwuR4gMqFXac7iRFmZG1x1hXxhLQiDS78kyTAa9uZGXXhtXcRpmFvaC+nj E55gTtnPjTbbWwuRgAlnU7JRUYObVVls8WdJkfGs4ymlX73yCgYeH9/jqBi/GSglSTpq HnwA== X-Received: by 10.50.28.101 with SMTP id a5mr11888119igh.57.1440369941115; Sun, 23 Aug 2015 15:45:41 -0700 (PDT) Original-Received: by 10.36.146.193 with HTTP; Sun, 23 Aug 2015 15:45:41 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: OYIBvoMu-dOnO0z5veCTDQO01iE X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:4001:c05::236 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:189091 Archived-At: On Mon, Aug 24, 2015 at 12:26 AM, Stefan Monnier wrote: > 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%. Ok, we can always check for conservative scanning at compile to enable modules. > 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). So if I understand correctly, with conservative scanning there's no need to call UNGCPRO? > I don't want to have to convert between emacs_value and Lisp_Object, > they should be one and the same. Ok, I'll keep casting Lisp_Object to void* then. Since module writer will often need to use Lisp_Object as handle for their own struct pointers, I was thinking adding a way to register finalizer functions to the API.