From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 22 Nov 2015 10:50:07 -0800 Organization: UCLA Computer Science Department Message-ID: <56520E5F.706@cs.ucla.edu> References: <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <837fld6lps.fsf@gnu.org> <83610w5o97.fsf@gnu.org> <564FACF5.2080601@cs.ucla.edu> <564FBAA7.5030306@cs.ucla.edu> <5650F9CD.9030707@cs.ucla.edu> <83oaem2ebu.fsf@gnu.org> <83mvu62cst.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1448218241 25897 80.91.229.3 (22 Nov 2015 18:50:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 18:50:41 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, emacs-devel@gnu.org To: Philipp Stephani , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 19:50:31 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 1a0ZiY-0006Yj-Cr for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 19:50:30 +0100 Original-Received: from localhost ([::1]:57088 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0ZiY-0008FI-Dy for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 13:50:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56215) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0ZiI-0008FC-7Y for emacs-devel@gnu.org; Sun, 22 Nov 2015 13:50:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0ZiH-0007NN-BM for emacs-devel@gnu.org; Sun, 22 Nov 2015 13:50:14 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0ZiD-0007MP-Fl; Sun, 22 Nov 2015 13:50:09 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id E665D1601AA; Sun, 22 Nov 2015 10:50:08 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id lFR5rMWB672m; Sun, 22 Nov 2015 10:50:08 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 36F8C1605AF; Sun, 22 Nov 2015 10:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id NHe2lbQJ5SxY; Sun, 22 Nov 2015 10:50:08 -0800 (PST) Original-Received: from [192.168.1.9] (pool-100-32-155-148.lsanca.fios.verizon.net [100.32.155.148]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 0FF991601AA; Sun, 22 Nov 2015 10:50:08 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:195049 Archived-At: Thanks for the patch, but this handles only part of the problem, namely, the memory allocated by emacs-module.c directly. We need a way for modules themselves to allocate memory that is properly accounted for, and this allocation should be nearly as convenient as xmalloc so that modules don't need to check for failure after each allocation. Since emacs-module.c can invoke xmalloc, surely it can export a memory-allocator function implemented via xmalloc, using the same techniques emacs-module.c is already using to call xmalloc in your patch. This should work regardless of whether the module is written in C or C++.