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 13:19:44 +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=001a11c38496ef1044051fa0cdc9 X-Trace: ger.gmane.org 1442150404 24608 80.91.229.3 (13 Sep 2015 13:20:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Sep 2015 13:20:04 +0000 (UTC) Cc: Tom Tromey , Paul Eggert , Stephen Leake , Daniel Colascione , Emacs development discussions To: Stefan Monnier , =?UTF-8?Q?Aur=C3=A9lien_Aptel?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Sep 13 15:20:03 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 1Zb7CK-0007Qc-FZ for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 15:20:00 +0200 Original-Received: from localhost ([::1]:35878 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb7CJ-0005qB-Q3 for ged-emacs-devel@m.gmane.org; Sun, 13 Sep 2015 09:19:59 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45124) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb7CG-0005pn-2B for emacs-devel@gnu.org; Sun, 13 Sep 2015 09:19:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zb7CE-0001Os-RU for emacs-devel@gnu.org; Sun, 13 Sep 2015 09:19:56 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:35991) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zb7CE-0001NT-Gd for emacs-devel@gnu.org; Sun, 13 Sep 2015 09:19:54 -0400 Original-Received: by wicgb1 with SMTP id gb1so110478266wic.1 for ; Sun, 13 Sep 2015 06:19:53 -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=SSnccgoMLlzaxAAho5uCRTnoC3eIxoVhCG5il1SGpvs=; b=JrPbU3vt0BUPwWvyphLXf3rFX41f4yLXJJ3V2egDi/KLaAyGqen15BfQD/lCmBajdf 5ugtflYr+FmW+ojpMQEdrJdISdFJzJr+aGWkWV67gScPT6DcRfOXkl20dK0cDKFOPhfV 3c6onsnQhQBLrGjnH/ZFZ8KwSnyOudo6oS7cnUaeog3AyoI28nP2RFeBhqYkXRkNj5j8 xSplq/FGRgMhF2j+wJ03WDrPI1nbxOjLjTXeSDtA7g1E7fO5ngTLEyADEp18mgnskAMY AHuIE7tZfuj+pIORrJG8rzHtN/9lq8ooR4WibJSQ/M0lhRiuNJsUCOELB2l8JrD+zy7J mSlA== X-Received: by 10.180.149.203 with SMTP id uc11mr16203026wib.7.1442150393776; Sun, 13 Sep 2015 06:19:53 -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::22b 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:189889 Archived-At: --001a11c38496ef1044051fa0cdc9 Content-Type: text/plain; charset=UTF-8 Stefan Monnier schrieb am So., 13. Sep. 2015 um 15:14 Uhr: > > The case where a module calls an emacs function that ends up calling > > signal/error. > > OK, what are you worried about w.r.t that case? > It's not possible to skip frames in module code using longjmp, so module_funcall needs to set up handlers before calling Ffuncall. > > > I don't know enough about how signaling and unwind-protect work. It's > > just black stack magic for me right now :) > > Fsignal works using longjmp. unwind-protect (and dynamic let-bindings) > works by adding things onto a stack which Fsignal will run just prior to > calling longjmp. > > > I think we just need to implement funcall (from the module API) like > this: > > > global error = 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 > > ret = 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. > > I don't understand what kind of error handling you have in mind. > How/why/when would we use things like error_get, error_clear, etc...? > Because setjmp/longjmp and therefore Fthrow/Fsignal don't work, you need to design a different error handling API that doesn't rely on non-local jumps. There are three options: return values, output parameters, thread-local state. All three have their pros and cons; Daniel opted for the third. The error_... functions are needed to access that thread-local state. > > > I didn't think about the case where a module calls Fthrow but my guess > > is it will just work. I have to test thoroughly what I have already > > anyway, I'll see if it works. > > Fthrow uses the same technique as Fsignal, and I think your intuition is > right: it should just work (for both). > No, it can't. See Daniel's initial posting where he designed the module API. --001a11c38496ef1044051fa0cdc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Stefan= Monnier <monnier@iro.umontr= eal.ca> schrieb am So., 13. Sep. 2015 um 15:14=C2=A0Uhr:
> The case where a module calls an emacs fu= nction that ends up calling
> signal/error.

OK, what are you worried about w.r.t that case?

It's not possible to skip frames in module code using longjmp,= so module_funcall needs to set up handlers before calling Ffuncall.
<= div>=C2=A0

> I don't know enough about how signaling and unwind-protect work. I= t's
> just black stack magic for me right now :)

Fsignal works using longjmp.=C2=A0 unwind-protect (and dynamic let-bindings= )
works by adding things onto a stack which Fsignal will run just prior to calling longjmp.

> I think we just need to implement funcall (from the module API) like t= his:

>=C2=A0 =C2=A0 =C2=A0global error =3D 0

>=C2=A0 =C2=A0 =C2=A0module_funcall(fun, args):
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// wrap (protect?) this with the righ= t code
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// - to keep the control
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// - set ret to nil and error to 1 in= case of error
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret =3D Ffuncall(fun, args)

>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return 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.

I don't understand what kind of error handling you have in mind.
How/why/when would we use things like error_get, error_clear, etc...?

Because setjmp/longjmp and therefore Fthrow/= Fsignal don't work, you need to design a different error handling API t= hat doesn't rely on non-local jumps. There are three options: return va= lues, output parameters, thread-local state. All three have their pros and = cons; Daniel opted for the third. The error_... functions are needed to acc= ess that thread-local state.
=C2=A0

> I didn't think about the case where a module calls Fthrow but my g= uess
> is it will just work. I have to test thoroughly what I have already > anyway, I'll see if it works.

Fthrow uses the same technique as Fsignal, and I think your intuition is right: it should just work (for both).

No, it can't. See Daniel's initial= posting where he designed the module API.=C2=A0
--001a11c38496ef1044051fa0cdc9--