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: Thu, 19 Nov 2015 22:45:51 +0000 Message-ID: References: <877flswse5.fsf@lifelogs.com> <8737wgw7kf.fsf@lifelogs.com> <87io5bv1it.fsf@lifelogs.com> <87egfzuwca.fsf@lifelogs.com> <876118u6f2.fsf@lifelogs.com> <8737w3qero.fsf@lifelogs.com> <831tbn9g9j.fsf@gnu.org> <878u5upw7o.fsf@lifelogs.com> <83ziya8xph.fsf@gnu.org> <83y4du80xo.fsf@gnu.org> <564DF0F6.5060501@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0102def4eb0f6e0524ec85b5 X-Trace: ger.gmane.org 1447973173 20956 80.91.229.3 (19 Nov 2015 22:46:13 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 19 Nov 2015 22:46:13 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii , Ted Zlatanov , =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Nov 19 23:46:12 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 1ZzXxy-0000rp-7Y for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 23:46:10 +0100 Original-Received: from localhost ([::1]:44367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzXxx-0004AA-49 for ged-emacs-devel@m.gmane.org; Thu, 19 Nov 2015 17:46:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54870) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzXxs-00049f-PY for emacs-devel@gnu.org; Thu, 19 Nov 2015 17:46:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZzXxr-0003kF-IW for emacs-devel@gnu.org; Thu, 19 Nov 2015 17:46:04 -0500 Original-Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:36761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZzXxp-0003jp-Nu; Thu, 19 Nov 2015 17:46:01 -0500 Original-Received: by wmww144 with SMTP id w144so257439275wmw.1; Thu, 19 Nov 2015 14:46:01 -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=mqvgw0BtrG1YRgPqaFR210GaRupknusoGeGX2L5CEWE=; b=DuSXZwvtrAm2+Q8qVgQJhY0WbTGHAbHjXpeWnGVhu4rVOGpvQqnxSQ8FwTwZKAapiF 3uuApbHE+gf2ZTspOkgb0anODxhR1rJqGpxYUgRzVRmAH9UVC8YG7bdRkCOILBjSTZK7 pebCVMIwNuPIvFELeJGak8P6gSVqBx1mdp/KzVJ7PTCY80yQEslrNPHw9D4FRzUaLwYE 1EpNcxWC6BDyNw8fOVerMDvdwUjqYX4qk7y/YtgO6Mc244lA8ClaQKq7/5t8mJdrvxAb uX37sQiU+6ByuFF6n9m2rKDM8Y0hhpRgYXMg1UERgntQ9ER1sOiJA1NTyOlt5rFUPNoL 1TzA== X-Received: by 10.194.87.39 with SMTP id u7mr11111533wjz.11.1447973161207; Thu, 19 Nov 2015 14:46:01 -0800 (PST) In-Reply-To: <564DF0F6.5060501@cs.ucla.edu> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c09::232 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:194827 Archived-At: --089e0102def4eb0f6e0524ec85b5 Content-Type: text/plain; charset=UTF-8 Paul Eggert schrieb am Do., 19. Nov. 2015 um 16:55 Uhr: > The main thing I noticed (that was not already in your list or in my > upcoming changes) are some problems in memory allocation. The module > code calls malloc directly, instead of xmalloc, for reasons I don't > understand. This leads to problems, e.g., the memory is not properly > accounted for by the memory profiler. Why can't the new module code > invoke xmalloc? More generally, how should modules obtain memory in an > Emacs-friendly way? > The problem with xmalloc is that it can signal (i.e. call longjmp). Modules are generally not prepared for long jumps, so it's important that no longjmp escapes into module code. The easiest way to ensure this is to make code not call longjmp in the first place. Some of the code in module.c does call longjmp; that is protected by appropriate calls to setjmp. We could do that with all code, but for cases like malloc it seemed simple enough to avoid the calls to longjmp altogether. Maybe we should add a variant that behaves like xmalloc but is guaranteed to never call longjmp? > > Also, the file name "emacs_module.h" doesn't use the usual Emacs style > rules; hyphen not underscore. If a hyphen is preferred, feel free to rename. > But as you say, "module.h" would be better > anyway. I'll change it to "module.h" for now; if there's some reason it > needs an "emacs" prefix we can change it to "emacs-module.h" later. > > Please don't use module.h; this header file is the only one that is intended for module authors to include, so it needs a globally unique name which should start with 'emacs'. > There are some other things I noticed which I'll try to summarize after > fixing the stuff that's easy to fix (missing copyright notices, > formatting, etc.). > > --089e0102def4eb0f6e0524ec85b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Paul E= ggert <eggert@cs.ucla.edu> = schrieb am Do., 19. Nov. 2015 um 16:55=C2=A0Uhr:
The main thing I noticed (that was not already in your list o= r in my
upcoming changes) are some problems in memory allocation. The module
code calls malloc directly, instead of xmalloc, for reasons I don't
understand. This leads to problems, e.g., the memory is not properly
accounted for by the memory profiler. Why can't the new module code
invoke xmalloc? More generally, how should modules obtain memory in an
Emacs-friendly way?

The problem with xm= alloc is that it can signal (i.e. call longjmp). Modules are generally not = prepared for long jumps, so it's important that no longjmp escapes into= module code. The easiest way to ensure this is to make code not call longj= mp in the first place.
Some of the code in module.c does call lon= gjmp; that is protected by appropriate calls to setjmp. We could do that wi= th all code, but for cases like malloc it seemed simple enough to avoid the= calls to longjmp altogether.
Maybe we should add a variant that = behaves like xmalloc but is guaranteed to never call longjmp?
=C2= =A0

Also, the file name "emacs_module.h" doesn't use the usual Em= acs style
rules; hyphen not underscore.

If a hyphen i= s preferred, feel free to rename.
=C2=A0
But as you say, "module.h" would be better
anyway. I'll change it to "module.h" for now; if there's = some reason it
needs an "emacs" prefix we can change it to "emacs-module.h&= quot; later.


Please don't use module.h; this he= ader file is the only one that is intended for module authors to include, s= o it needs a globally unique name which should start with 'emacs'.<= /div>
=C2=A0
There are some other things I noticed which I'll try to summarize after=
fixing the stuff that's easy to fix (missing copyright notices,
formatting, etc.).

--089e0102def4eb0f6e0524ec85b5--