From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 23 Nov 2015 18:35:11 +0200 Message-ID: <837fl81xog.fsf@gnu.org> References: <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> <56520E5F.706@cs.ucla.edu> <831tbh3ket.fsf@gnu.org> <87bnalzb1i.fsf@tromey.com> <56533EDC.1070009@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448296568 17818 80.91.229.3 (23 Nov 2015 16:36:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 23 Nov 2015 16:36:08 +0000 (UTC) Cc: dancol@dancol.org, tzz@lifelogs.com, emacs-devel@gnu.org, p.stephani2@gmail.com, aurelien.aptel+emacs@gmail.com, tom@tromey.com To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 23 17:35:58 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 1a0u5q-0004je-8r for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2015 17:35:54 +0100 Original-Received: from localhost ([::1]:33296 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0u5q-0002pr-Q2 for ged-emacs-devel@m.gmane.org; Mon, 23 Nov 2015 11:35:54 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0u5V-0002pB-De for emacs-devel@gnu.org; Mon, 23 Nov 2015 11:35:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0u5R-00053G-9R for emacs-devel@gnu.org; Mon, 23 Nov 2015 11:35:33 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:34241) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0u5R-000532-1A for emacs-devel@gnu.org; Mon, 23 Nov 2015 11:35:29 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NYA002000NVI200@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Mon, 23 Nov 2015 18:35:24 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYA002GX0QRB650@a-mtaout20.012.net.il>; Mon, 23 Nov 2015 18:35:16 +0200 (IST) In-reply-to: <56533EDC.1070009@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:195119 Archived-At: > Cc: Philipp Stephani , aurelien.aptel+emacs@gmail.com, > tzz@lifelogs.com, dancol@dancol.org, emacs-devel@gnu.org > From: Paul Eggert > Date: Mon, 23 Nov 2015 08:29:16 -0800 > > Yes, if another library calls the system malloc directly, the module > author will be stuck with that behavior. However, many libraries let or > require the caller to allocate memory, or provide ways for the caller to > specify the memory-allocator functions, and module authors should prefer > this to having the libraries invoke malloc directly, because Emacs wants > to do memory accounting etc. I agree. This is even more important in the Windows build of Emacs, because we provide our own implementation of malloc and friends, which should be less prone to heap fragmentation issues (it is an emulation of mmap-based malloc).