From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Throw an exception when mutating read-only data Date: Fri, 14 Apr 2017 11:04:55 +0200 Message-ID: <8760i78img.fsf@pobox.com> References: <20170402101131.10387-1-wingo@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492160720 14241 195.159.176.226 (14 Apr 2017 09:05:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 09:05:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: guile-devel@gnu.org To: Pedro Alves Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Apr 14 11:05:16 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cyxAJ-0003ap-OE for guile-devel@m.gmane.org; Fri, 14 Apr 2017 11:05:16 +0200 Original-Received: from localhost ([::1]:52433 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyxAP-0001D1-Ph for guile-devel@m.gmane.org; Fri, 14 Apr 2017 05:05:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cyxAF-0001AI-Tp for guile-devel@gnu.org; Fri, 14 Apr 2017 05:05:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cyxA9-000229-MX for guile-devel@gnu.org; Fri, 14 Apr 2017 05:05:11 -0400 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:52772 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cyxA9-000223-J3 for guile-devel@gnu.org; Fri, 14 Apr 2017 05:05:05 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 4589E6F6A3; Fri, 14 Apr 2017 05:05:04 -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=pGDtV9hPiBZbDn4XeOtwxd+FmDg=; b=D0MU3A UjhVm7zuNfd6cUNLUck3k0Y3lG65oPERgcFCFKx4lJZHIjXlmP3iemKnVYKBYbQB lk2PM8evESPqmO582hPZRUpsMrfoVqA4guY6h32CqEbjXwnUVzUE8mE57Yrfa3Ih oI24BS5c7ztdqgfGYcTJ+dz5GsbPDaL5TSgro= 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=r3DTiDQ7vIGOqhHEeeUlLrSinbCqYrN+ Rrfv2IAiYUIOiZBZeajta27CKZw0wV/5zwLMquGW39B9UjnNrx0x8j6r7QLod9I4 aUqcy6WVmR/WDBxJ6Wqg81ipyOKPIZDaqPPlw6SlHifQds572CSzBXj5b7P1DKxs M8reVt73BC8= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 3DCA36F6A2; Fri, 14 Apr 2017 05:05:04 -0400 (EDT) Original-Received: from clucks (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 130ED6F6A0; Fri, 14 Apr 2017 05:05:02 -0400 (EDT) In-Reply-To: (Pedro Alves's message of "Mon, 3 Apr 2017 11:49:45 +0100") X-Pobox-Relay-ID: 724C6A36-20F1-11E7-B388-07D2064AB293-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.66 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.lisp.guile.devel:19104 Archived-At: Hi Pedro, On Mon 03 Apr 2017 12:49, Pedro Alves writes: > AFAICS, guile uses bare setjmp/longjmp for exceptions. > > But, one should not use longjmp to jump out of a signal handler, since > that leaves the signal mask disabled if the system automatically masks > the signal on handler entry (which is true on e.g., the Linux kernel). > Instead, sigsetjmp+siglongjmp should be used, in order to restore > the signal mask. > > Since sigsetjmp is heavy weight (it requires a system call to get the current > mask [1]), I'd recommend instead to use sigsetjmp/siglongjmp around the > problematic code area, and then call scm_misc_error back in mainline code (as > opposed to changing SCM_I_SETJMP/SCM_I_LONGJMP and forcing all exception > handling to use sigsetjmp+siglongjmp). > > [1] - See > and the linked URL for a practical difference that made in GDB. Thanks very much for this information! I was unaware of how this worked. This is the first SIGSEGV handler I have written :) In Guile the details are similar as in GDB's try/catch, though with some slight differences. Currently the usual way Guile does things is to SCM_I_SETJMP only once before entering the bytecode interpreter. Establishing a "catch" within Scheme code re-uses that jump buffer. Currently the "throw" code will unwind the VM state and then do a SCM_I_LONGJMP back to the jump buffer that corresponds to that catch, which will re-enter the bytecode interpreter with the new VM state. Multiple "catch" instantiations can share the same jump buffer. Probably at some point in the future we optimize things so that if the "throw" happens from bytecode, within the same VM invocation as the "catch", that we can avoid the SCM_I_LONGJMP on abort as well. All of this applies only to Scheme code though. If you have C code that throws an error, it will always SCM_I_LONGJMP; and if you call into the VM from C or establish a "catch" from C, it will SCM_I_SETJMP before entering the VM. So in that situation we'd be seeing the performance impact for signal mask things. I guess the conclusion here would be that we would need to measure performance a bit before making a change like this. Andy