From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Sun, 22 Nov 2015 19:58:26 +0000 Message-ID: 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> <56520E5F.706@cs.ucla.edu> <831tbh3ket.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=047d7bb04dc4c5616b0525268882 X-Trace: ger.gmane.org 1448222328 28511 80.91.229.3 (22 Nov 2015 19:58:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 22 Nov 2015 19:58:48 +0000 (UTC) Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, eggert@cs.ucla.edu, dancol@dancol.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Nov 22 20:58:47 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 1a0ama-00060O-J0 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 20:58:44 +0100 Original-Received: from localhost ([::1]:57283 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0ama-0005Ba-N5 for ged-emacs-devel@m.gmane.org; Sun, 22 Nov 2015 14:58:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42638) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0amW-0005BT-KH for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:58:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a0amV-0005mJ-OZ for emacs-devel@gnu.org; Sun, 22 Nov 2015 14:58:40 -0500 Original-Received: from mail-wm0-x236.google.com ([2a00:1450:400c:c09::236]:35615) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a0amT-0005m1-Rr; Sun, 22 Nov 2015 14:58:38 -0500 Original-Received: by wmuu63 with SMTP id u63so31582775wmu.0; Sun, 22 Nov 2015 11:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=519c2M6YYhEZ6qmtXGJCRBsZwpgYYahb3NrG9nw4zQI=; b=Tb8rWSLm1al+sRESWzBKfwYJmEv9w+fKNtD9xBwycavyqE6sjJX/BfYXwAT7ZRU1Me WY/F02fWJQLvQYmf38nZciu6jmbjtCm+7t4/vhbd8+OyYa/TT27ttPjH/pnWUah5cXOg BitPkPfNEfX0/3u8m0WGMZYSrmGy1EWi+3rTfAwvbqrDkyVfLTP/9yC9m/j7GKoJh0yY f5gjK42UhkkfTPsPW9ytX1gQG8ICFwnIyShixvCHk6+rzp10ut3YIjIrAb2ll1Bi7Quc pHI9zy7S/vM4fPDj0UsU8LOv6Q4fQ9DFBgCnZLs7slYgGLDLLAPXRtSaq3a3atzf4/UV tBMA== X-Received: by 10.195.13.135 with SMTP id ey7mr26195200wjd.25.1448222317048; Sun, 22 Nov 2015 11:58:37 -0800 (PST) In-Reply-To: <831tbh3ket.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::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:195063 Archived-At: --047d7bb04dc4c5616b0525268882 Content-Type: multipart/alternative; boundary=047d7bb04dc4c561660525268880 --047d7bb04dc4c561660525268880 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am So., 22. Nov. 2015 um 20:26 Uhr: > > From: Philipp Stephani > > Date: Sun, 22 Nov 2015 19:19:49 +0000 > > Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, > > Emacs developers , Daniel Colascione < > dancol@dancol.org> > > > > 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. > > > > This is _impossible_ without using longjmp. > > Why? Why cannot emacs-module.c expose an allocator, which modules > will then use as a sole source of memory? And why such an allocator > cannot do exactly what you did in your patch? > I've attached a patch for such an allocator, but it doesn't use longjmp. --047d7bb04dc4c561660525268880 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 22. Nov. 2015 um 20:26=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 22 Nov 2015 19:19:49 +0000
> Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Emacs developers <emacs-devel@gnu.org>, Daniel Colas= cione <dancol@dan= col.org>
>
>=C2=A0 =C2=A0 =C2=A0Thanks for the patch, but this handles only part of= the problem, namely,
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0memory allocated by emacs-module.c directly. We nee= d a way for modules
>=C2=A0 =C2=A0 =C2=A0themselves to allocate memory that is properly acco= unted for, and this
>=C2=A0 =C2=A0 =C2=A0allocation should be nearly as convenient as xmallo= c so that modules don't
>=C2=A0 =C2=A0 =C2=A0need
>=C2=A0 =C2=A0 =C2=A0to check for failure after each allocation.
>
> This is _impossible_ without using longjmp.

Why?=C2=A0 Why cannot emacs-module.c expose an allocator, which modules
will then use as a sole source of memory?=C2=A0 And why such an allocator cannot do exactly what you did in your patch?

I've attached a patch for such an allocator, but it doesn't = use longjmp.=C2=A0
--047d7bb04dc4c561660525268880-- --047d7bb04dc4c5616b0525268882 Content-Type: application/octet-stream; name="0002-Add-functions-to-access-the-Emacs-allocator.patch" Content-Disposition: attachment; filename="0002-Add-functions-to-access-the-Emacs-allocator.patch" Content-Transfer-Encoding: base64 Content-ID: <15130c69ef6aa2e0aa51> X-Attachment-Id: 15130c69ef6aa2e0aa51 RnJvbSA2YTM5Y2VlMzA4NDg0ODliMTNkZGVmMDI2YTEzNzA2MzUzMTQ1MjYyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IFN1biwgMjIgTm92IDIwMTUgMjA6NTI6NTUgKzAxMDAKU3ViamVjdDogW1BBVENIIDIvMl0g QWRkIGZ1bmN0aW9ucyB0byBhY2Nlc3MgdGhlIEVtYWNzIGFsbG9jYXRvcgoKKiBlbWFjcy1tb2R1 bGUuYyAobW9kdWxlX2FsbG9jYXRlX3Jhd19tZW1vcnkpCihtb2R1bGVfZnJlZV9yYXdfbWVtb3J5 KTogbmV3IGZ1bmN0aW9ucwotLS0KIHNyYy9lbWFjcy1tb2R1bGUuYyB8IDIxICsrKysrKysrKysr KysrKysrKysrKwogc3JjL2VtYWNzLW1vZHVsZS5oIHwgMTEgKysrKysrKysrKysKIDIgZmlsZXMg Y2hhbmdlZCwgMzIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy1tb2R1bGUu YyBiL3NyYy9lbWFjcy1tb2R1bGUuYwppbmRleCA4NzA1MjgwLi4xZjRlM2Y1IDEwMDY0NAotLS0g YS9zcmMvZW1hY3MtbW9kdWxlLmMKKysrIGIvc3JjL2VtYWNzLW1vZHVsZS5jCkBAIC0yODcsNiAr Mjg3LDI1IEBAIG1vZHVsZV9tYWtlX2dsb2JhbF9yZWYgKGVtYWNzX2VudiAqZW52LCBlbWFjc192 YWx1ZSByZWYpCiAgIHJldHVybiBhbGxvY2F0ZV9lbWFjc192YWx1ZSAoJmdsb2JhbF9zdG9yYWdl LCBuZXdfb2JqKTsKIH0KIAorc3RhdGljIHZvaWQgKgorbW9kdWxlX2FsbG9jYXRlX3Jhd19tZW1v cnkgKGVtYWNzX2VudiAqZW52LCBwdHJkaWZmX3Qgc2l6ZSkKK3sKKyAgY2hlY2tfbWFpbl90aHJl YWQgKCk7CisgIGVhc3NlcnQgKG1vZHVsZV9ub25fbG9jYWxfZXhpdF9jaGVjayAoZW52KSA9PSBl bWFjc19mdW5jYWxsX2V4aXRfcmV0dXJuKTsKKyAgTU9EVUxFX0hBTkRMRV9TSUdOQUxTOworICBy ZXR1cm4geG1hbGxvYyAoc2l6ZSk7Cit9CisKK3N0YXRpYyB2b2lkCittb2R1bGVfZnJlZV9yYXdf bWVtb3J5IChlbWFjc19lbnYgKmVudiwgdm9pZCAqbWVtb3J5KQoreworICBjaGVja19tYWluX3Ro cmVhZCAoKTsKKyAgZWFzc2VydCAobW9kdWxlX25vbl9sb2NhbF9leGl0X2NoZWNrIChlbnYpID09 IGVtYWNzX2Z1bmNhbGxfZXhpdF9yZXR1cm4pOworICBNT0RVTEVfSEFORExFX1NJR05BTFNfVk9J RDsKKyAgZWFzc2VydCAobWVtb3J5ICE9IE5VTEwpOworICByZXR1cm4geGZyZWUgKG1lbW9yeSk7 Cit9CisKIHN0YXRpYyB2b2lkCiBtb2R1bGVfZnJlZV9nbG9iYWxfcmVmIChlbWFjc19lbnYgKmVu diwgZW1hY3NfdmFsdWUgcmVmKQogewpAQCAtOTUzLDYgKzk3Miw4IEBAIGluaXRpYWxpemVfZW52 aXJvbm1lbnQgKHN0cnVjdCBlbnZfc3RvcmFnZSAqZW52KQogICBlbnYtPnB1Yi5wcml2YXRlX21l bWJlcnMgPSAmZW52LT5wcml2OwogICBlbnYtPnB1Yi5tYWtlX2dsb2JhbF9yZWYgPSBtb2R1bGVf bWFrZV9nbG9iYWxfcmVmOwogICBlbnYtPnB1Yi5mcmVlX2dsb2JhbF9yZWYgPSBtb2R1bGVfZnJl ZV9nbG9iYWxfcmVmOworICBlbnYtPnB1Yi5hbGxvY2F0ZV9yYXdfbWVtb3J5ID0gbW9kdWxlX2Fs bG9jYXRlX3Jhd19tZW1vcnk7CisgIGVudi0+cHViLmZyZWVfcmF3X21lbW9yeSA9IG1vZHVsZV9m cmVlX3Jhd19tZW1vcnk7CiAgIGVudi0+cHViLm5vbl9sb2NhbF9leGl0X2NoZWNrID0gbW9kdWxl X25vbl9sb2NhbF9leGl0X2NoZWNrOwogICBlbnYtPnB1Yi5ub25fbG9jYWxfZXhpdF9jbGVhciA9 IG1vZHVsZV9ub25fbG9jYWxfZXhpdF9jbGVhcjsKICAgZW52LT5wdWIubm9uX2xvY2FsX2V4aXRf Z2V0ID0gbW9kdWxlX25vbl9sb2NhbF9leGl0X2dldDsKZGlmZiAtLWdpdCBhL3NyYy9lbWFjcy1t b2R1bGUuaCBiL3NyYy9lbWFjcy1tb2R1bGUuaAppbmRleCAwNmZjNGMwLi5lY2VhZDIzIDEwMDY0 NAotLS0gYS9zcmMvZW1hY3MtbW9kdWxlLmgKKysrIGIvc3JjL2VtYWNzLW1vZHVsZS5oCkBAIC05 NSw2ICs5NSwxNyBAQCBzdHJ1Y3QgZW1hY3NfZW52XzI1CiAgIHZvaWQgKCpmcmVlX2dsb2JhbF9y ZWYpIChlbWFjc19lbnYgKmVudiwKIAkJCSAgIGVtYWNzX3ZhbHVlIGdsb2JhbF9yZWZlcmVuY2Up OwogCisgIC8qIFVzZXMgdGhlIEVtYWNzIG1lbW9yeSBhbGxvY2F0b3IgdG8gYWxsb2NhdGUgcmF3 IG1lbW9yeS4gIFJldHVybnMKKyAgICAgTlVMTCBpZiBhbGxvY2F0aW9uIGZhaWxzLiAgVXNpbmcg dGhpcyBmdW5jdGlvbiBvdmVyIG1hbGxvYygzKSBoYXMKKyAgICAgdGhlIGFkdmFudGFnZSB0aGF0 IGlucHV0IGlzIGNvcnJlY3RseSBibG9ja2VkIGFuZCB0aGUgbWVtb3J5CisgICAgIHByb2ZpbGVy IGlzIG5vdGlmaWVkIGFib3V0IHRoZSBhbGxvY2F0aW9uLiAgTWVtb3J5IGFsbG9jYXRlZCB3aXRo CisgICAgIHRoaXMgZnVuY3Rpb24gbXVzdCBiZSBmcmVlZCBieSBmcmVlX3Jhd19tZW1vcnkuICAq LworICB2b2lkICooKmFsbG9jYXRlX3Jhd19tZW1vcnkpIChlbWFjc19lbnYgKmVudiwgcHRyZGlm Zl90IHNpemUpOworCisgIC8qIEZyZWVzIGEgYmxvY2sgb2YgbWVtb3J5IGFsbG9jYXRlZCBieSBh bGxvY2F0ZV9yYXdfbWVtb3J5LiAgVGhlCisgICAgIHBvaW50ZXIgdG8gdGhlIG1lbW9yeSBibG9j ayBtdXN0IG5vdCBiZSBOVUxMLiAgKi8KKyAgdm9pZCAoKmZyZWVfcmF3X21lbW9yeSkgKGVtYWNz X2VudiAqZW52LCB2b2lkICptZW1vcnkpOworCiAgIC8qIE5vbi1sb2NhbCBleGl0IGhhbmRsaW5n LiAgKi8KIAogICBlbnVtIGVtYWNzX2Z1bmNhbGxfZXhpdCAoKm5vbl9sb2NhbF9leGl0X2NoZWNr KSAoZW1hY3NfZW52ICplbnYpOwotLSAKMi42LjMKCg== --047d7bb04dc4c5616b0525268882--