From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Exception-safety for C++ code integrated with Guile. Date: Tue, 10 Mar 2015 22:15:26 +0100 Message-ID: <87vbi8y2oh.fsf@pobox.com> References: <474913203.jcqxqasMgP@basis> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1426022167 17866 80.91.229.3 (10 Mar 2015 21:16:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Mar 2015 21:16:07 +0000 (UTC) Cc: guile-devel@gnu.org To: Taahir Ahmed Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Tue Mar 10 22:15:53 2015 Return-path: Envelope-to: guile-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 1YVRVA-00036V-7Y for guile-devel@m.gmane.org; Tue, 10 Mar 2015 22:15:44 +0100 Original-Received: from localhost ([::1]:51451 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVRV9-0003bR-81 for guile-devel@m.gmane.org; Tue, 10 Mar 2015 17:15:43 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVRV3-0003aJ-Pi for guile-devel@gnu.org; Tue, 10 Mar 2015 17:15:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YVRUy-00006i-Kq for guile-devel@gnu.org; Tue, 10 Mar 2015 17:15:37 -0400 Original-Received: from pb-sasl1.int.icgroup.com ([208.72.237.25]:57991 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YVRUy-0008Ue-56 for guile-devel@gnu.org; Tue, 10 Mar 2015 17:15:32 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id AC5343CA12; Tue, 10 Mar 2015 17:15:30 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=nwPFTxMUSBAwhBpce0oCqZbbXug=; b=ly+wj9 MRvNVt/JBiOonoUvmvyYmDuIL8VDUp0mKbHVgJhK7CyOEUn/EXKawOaCJ6Po5lLH 5X2L7Ru+CGJBLi7DhWzl3ZR13fnS2LccfceMBByxi6ucM7MTEAtK3HRyH6Om0q6V 9bGuqQGASCw0TaMt1+KtaL6eFbHy0BGeqouKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; q=dns; s=sasl; b=qRHN+QxLNi3T1O4dmMoS9qOutpUFz29K t2DotKnnd4ARcRmTWbuE5jWyGHR4xNnRlYXVYSKl/mEZbh7bEhEwjs9ZlwBh5by0 Jrvok6rYfYsltU8TwDjQLe+S5HL6UY97l/IWJtjcLBoJW6oZ4hieB+A7EEENo9q2 t2yfV0TRGUE= Original-Received: from pb-sasl1.int.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id A08873CA11; Tue, 10 Mar 2015 17:15:30 -0400 (EDT) Original-Received: from badger (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id C9BA43CA10; Tue, 10 Mar 2015 17:15:29 -0400 (EDT) In-Reply-To: <474913203.jcqxqasMgP@basis> (Taahir Ahmed's message of "Mon, 23 Feb 2015 15:59:43 -0600") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (gnu/linux) X-Pobox-Relay-ID: 9485A578-C76A-11E4-A561-B058D0B8C469-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.72.237.25 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:17695 Archived-At: Hi Taahir, On Mon 23 Feb 2015 22:59, Taahir Ahmed writes: > Over the past few days, I've been working on reducing the amount of > defensive coding that is required when writing Guile extensions using > C++. > > My primary goal is to ensure that destructors of automatic variables > are called if any Guile non-local control flow passes through a C++ > stack frame. I was thinking about this recently too, in the context of GDB's upcoming switch to C++, though I didn't get very far in the thinking. > 1) To check that I'm not duplicating any other ongoing work, Not that I know of. Doesn't matter anyway, a good solution is always acceptable :) > 2) To float two different implementation strategies and see which > one is the best choice going forward, and > > 3) To get clarification on some issues that I've encountered with a > prototype implementation. Cool. > The two major strategies I considered are: > > 1) Replace all uses of set/longjmp in the Guile source with C++ > exceptions. This approach is simple in some ways, and > complicated in others. I would hesitate to pursue this unless > Guile has some sort of longer-term plan to move towards C++. I am not C++-averse but a hypothetical move towards C++ in a Guile context doesn't necessarily mean moving towards use of exceptions. Scheme has fairly complicated control flow and embracing C++ exceptions doesn't necessarily solve things. For example an exception propagating over natively-compiled Scheme code would have to run dynwinds. Calling out to C++ would have to set up some sort of try/catch. Is that the right design? I don't know. (I do think that the C-stack-saving aspect of Guile's continuations is a silly thing, given that delimited continuations are more expressive, we can have escape-only continuations either way, and our VM and future native compilation pipeline means that we don't have so much rewinding of C stack frames, and in any case rewinding is unexpected and untested by most Guile core code, not to mention user code.) > 2) Replace all uses of set/longjmp with replacements (call them > eh_setjmp and eh_longjmp) that are based on libunwind [1]. No opinion other than a vague aversion to dependencies. > However, I've run into an issue --- many of Guile's uses of setjmp > don't conform to the C standard. In particular, after experiencing a > non-local return from setjmp, you're not allowed to access any > non-volatile local variables, but Guile does (see the local variable > mx in eval()). You are allowed to access variables that could never be assigned after the setjmp, AFAIK? Anyway how is mx accessed before being re-set after a prompt longjmp? Cheers, and thanks for looking at this, Andy -- http://wingolog.org/