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, 13 Sep 2015 12:54:12 +0000 Message-ID: References: <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> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d043c81d4a05d81051fa072c6 X-Trace: ger.gmane.org 1442148884 3555 80.91.229.3 (13 Sep 2015 12:54:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Sep 2015 12:54:44 +0000 (UTC) Cc: Tom Tromey , Paul Eggert , Stephen Leake , Daniel Colascione , Emacs development discussions To: =?UTF-8?Q?Aur=C3=A9lien_Aptel?= , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 13 14:54:40 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 1Zb6nn-0006mI-Cc for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 14:54:39 +0200 Original-Received: from localhost ([::1]:35797 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb6nm-0008Nq-Jr for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 08:54:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40218) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb6nZ-0008Nj-0s for emacs-devel@gnu.org; Sun, 13 Sep 2015 08:54:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zb6nX-0000fc-KF for emacs-devel@gnu.org; Sun, 13 Sep 2015 08:54:24 -0400 Original-Received: from mail-wi0-x235.google.com ([2a00:1450:400c:c05::235]:35546) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb6nX-0000dn-9D for emacs-devel@gnu.org; Sun, 13 Sep 2015 08:54:23 -0400 Original-Received: by wicge5 with SMTP id ge5so110795364wic.0 for ; Sun, 13 Sep 2015 05:54:22 -0700 (PDT) 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=QxwEQwOzp0JpDviDGRo3wYbuGJGJ0Wgl7EoF8yvr0Y8=; b=YThEA+0j12HI1U0Wx5eRPNH8ImSPsBbs5vrmBIe4AIlWZniXzidxqH/O8dskraoxNl STkt53I3j9lw0uXPtLkoaKJzLugUOUpgkMgSTS3+GwRjwPGcgJB5rNlvbqXlz4jI1dU+ z2QKL2a71nLPKQQldwgCf+F6uxa1K8XQLSV4i4PmNL8sE4AF2cI3xdWKrlDZiWVVbaej GSpgMw/A+XZOMQyFJouzLbf483lMfyyqMnAlhQ+5xHRFaIMdJZXI8mDJG3rDDGoAJQ6k MJ4jzX/0biyVRVxPHOtwPRWX1XnVyFxOnnSACOW8GHOD4do7hDq/bNQaUekNeZTClXo7 t8Ug== X-Received: by 10.180.90.107 with SMTP id bv11mr16295299wib.69.1442148861892; Sun, 13 Sep 2015 05:54:21 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::235 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:189885 Archived-At: --f46d043c81d4a05d81051fa072c6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Aur=C3=A9lien Aptel schrieb am So., 13. Se= p. 2015 um 01:11 Uhr: > On Sat, Sep 12, 2015 at 10:42 PM, Stefan Monnier > wrote: > > Can you give us more details about you mean by the above. > > Are you talking about how to handle things like calls to Fsignal, or to > > Fthrow, or how to provide access to unwind-protect and condition-case i= n > > to the module's? > > The case where a module calls an emacs function that ends up calling > signal/error. I don't know enough about how signaling and > unwind-protect work. It's just black stack magic for me right now :) > > They use longjmp, which doesn't work in modules. Your implementation needs to make sure that no longjmp ever escapes to module code, i.e. that none of the stackframes skipped by longjmp can lie inside a module. See what Daniel wrote above: "When Emacs calls a module function, the current thread's pending-error flag will be clear. When that module returns to Emacs, if the thread's pending-error flag is set, Emacs signals the condition corresponding to the current thread's error information. When the module calls an Emacs routine that would ordinarily signal, Emacs catches the signal at the stack frame just before control flow would return to the module, sets the pending-error flag, and returns to the module normally." > I think we just need to implement funcall (from the module API) like this= : > > global error =3D 0 > > module_funcall(fun, args): > // wrap (protect?) this with the right code > // - to keep the control > // - set ret to nil and error to 1 in case of error > Here you probably need to call both internal_catch and internal_condition_case. > ret =3D Ffuncall(fun, args) > > return ret > > The error is accessible via error_get(), error_clear() and > error_check() in the module API. error_get() is currently redundant > with error_check() unless we decide to return detailed errors. > > What do you mean with 'detailed errors'? At a minimum users need access to the handler type (condition-case or catch), the catch tag, the error symbol, and the error data. Most likely the stacktrace should also be provided. > I didn't think about the case where a module calls Fthrow but my guess > is it will just work. > It uses a different handler type and therefore will probably not work out of the box unless you call internal_catch. > > > Indeed it's not guaranteed at all. It's not even guaranteed that when > you > > call the GC, all dead objects will be collected. > > Ok. Finalizers are better than nothing I guess. > > Why would you need finalizers at all? There are usually wrong and useless in languages with nondeterministic garbage collection. --f46d043c81d4a05d81051fa072c6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Aur=C3= =A9lien Aptel <aurel= ien.aptel+emacs@gmail.com> schrieb am So., 13. Sep. 2015 um 01:11=C2= =A0Uhr:
On Sat, Sep 12, 2015 at 10:= 42 PM, Stefan Monnier
<monnier@i= ro.umontreal.ca> wrote:
> Can you give us more details about you mean by the above.
> Are you talking about how to handle things like calls to Fsignal, or t= o
> Fthrow, or how to provide access to unwind-protect and condition-case = in
> to the module's?

The case where a module calls an emacs function that ends up calling
signal/error. I don't know enough about how signaling and
unwind-protect work. It's just black stack magic for me right now :)

They use longjmp, which doesn't wo= rk in modules. Your implementation needs to make sure that no longjmp ever = escapes to module code, i.e. that none of the stackframes skipped by longjm= p can lie inside a module. See what Daniel wrote above:

"When Emacs calls a module function, the current thread's pe= nding-error
flag will be clear.=C2=A0 When that module returns to= Emacs, if the
thread's pending-error flag is set, Emacs sign= als the condition
corresponding to the current thread's error= information.

When the module calls an Emacs routi= ne that would ordinarily signal,
Emacs catches the signal at the = stack frame just before control flow
would return to the module, = sets the pending-error flag, and returns
to the module normally.&= quot;
=C2=A0
I think we just need to implement funcall (from the module API) like this:<= br>
=C2=A0 =C2=A0 global error =3D 0

=C2=A0 =C2=A0 module_funcall(fun, args):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // wrap (protect?) this with the right code
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // - to keep the control
=C2=A0 =C2=A0 =C2=A0 =C2=A0 // - set ret to nil and error to 1 in case of e= rror

Here you probably need to call bot= h internal_catch and internal_condition_case.
=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret =3D Ffuncall(fun, args)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 return ret

The error is accessible via error_get(), error_clear() and
error_check() in the module API. error_get() is currently redundant
with error_check() unless we decide to return detailed errors.


What do you mean with 'detailed er= rors'? At a minimum users need access to the handler type (condition-ca= se or catch), the catch tag, the error symbol, and the error data. Most lik= ely the stacktrace should also be provided.
=C2=A0
I didn't think about the case where a module calls Fthrow but my guess<= br> is it will just work.

It uses a differe= nt handler type and therefore will probably not work out of the box unless = you call internal_catch.
=C2=A0

> Indeed it's not guaranteed at all.=C2=A0 It's not even guarant= eed that when you
> call the GC, all dead objects will be collected.

Ok. Finalizers are better than nothing I guess.


Why would you need finalizers at all? = There are usually wrong and useless in languages with nondeterministic garb= age collection.=C2=A0
--f46d043c81d4a05d81051fa072c6--