From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Neil Jerram" Newsgroups: gmane.lisp.guile.devel Subject: Re: array handles and non-local exits Date: Wed, 17 Sep 2008 21:32:25 +0200 Message-ID: <49dd78620809171232n745ac8ecgd2c3936989ce723b@mail.gmail.com> References: <49dd78620809151317i3421081ey3337d678477046ab@mail.gmail.com> <87ljxsv80p.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1221680050 26925 80.91.229.12 (17 Sep 2008 19:34:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Sep 2008 19:34:10 +0000 (UTC) Cc: guile-devel@gnu.org To: "=?ISO-8859-1?Q?Ludovic_Court=E8s?=" Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Sep 17 21:35:07 2008 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1Kg2no-0003oW-5p for guile-devel@m.gmane.org; Wed, 17 Sep 2008 21:35:05 +0200 Original-Received: from localhost ([127.0.0.1]:60694 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kg2ml-0005uf-P7 for guile-devel@m.gmane.org; Wed, 17 Sep 2008 15:33:59 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kg2lQ-0005Y2-1f for guile-devel@gnu.org; Wed, 17 Sep 2008 15:32:36 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kg2lL-0005Tl-C3 for guile-devel@gnu.org; Wed, 17 Sep 2008 15:32:35 -0400 Original-Received: from [199.232.76.173] (port=50740 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kg2lL-0005TI-0r for guile-devel@gnu.org; Wed, 17 Sep 2008 15:32:31 -0400 Original-Received: from rv-out-0708.google.com ([209.85.198.251]:65366) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kg2lK-0005go-1J for guile-devel@gnu.org; Wed, 17 Sep 2008 15:32:30 -0400 Original-Received: by rv-out-0708.google.com with SMTP id k29so3722767rvb.6 for ; Wed, 17 Sep 2008 12:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=zjr/V+lEtXqKfKRs4Wt/+LSPI8XumIF+bDNr4uTaoJs=; b=jDgDOZm9vBS5bCVPEJHjINBoH2/ptSCVU7q46Eu1zH3mUj67zUT2Hm7sRW9dkVp2xI 07IHNM69VrpnlGqIuKJGEgJEgihCqXBZg/wPwvwL/0EBlnEQBxRdZo/vjZY1MchXPsGb 5Sarko++xwWLepkHn3rWxFG92JNjuhWqldvhA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=gKtnWyPByQ9gxU+r9GVvXa+IEiR5Ouexxwz916EJ/00s70M0SSbAItHoKavMfWr7MP swOi2aKg3z5uOt8YyYa6C3IP76zKCijDIJ2A6dH3RNIW9rYpwfHVPgortMXBLo+Vfa4T mBKnwHySxzvRdlKdSsRHw5WRPAWQ9Wg7NSvqc= Original-Received: by 10.141.129.14 with SMTP id g14mr6805034rvn.56.1221679945622; Wed, 17 Sep 2008 12:32:25 -0700 (PDT) Original-Received: by 10.140.142.15 with HTTP; Wed, 17 Sep 2008 12:32:25 -0700 (PDT) In-Reply-To: <87ljxsv80p.fsf@gnu.org> Content-Disposition: inline X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:7708 Archived-At: 2008/9/16 Ludovic Court=E8s : > > If `get_handle ()' creates a dynwind that ends in `release_handle ()', > then code like the following will no longer work as expected: > > scm_dynwind_begin (); > scm_dynwind_unwind_handler (); > scm array_get_handle (); > > ... > > scm_dynwind_end (); > scm_array_release_handle (); > > Perhaps that's what is implied by the manual's wording but I find it a > bit tricky. Yes, that definitely is what the manual means by "properly nested" - but I also agree that it is a bit tricky. >>> and (2) I don't know of any other function that does a dynwind behind >>> the scenes (IOW, let's not break the "rule of least surprise"). > > I meant "I don't know of a function that does a `dynwind_begin' > *alone*" (of course there are plenty of functions that do > `dynwind_begin' + `dynwind_end'). Yes, I see what you mean now. (The scm_dynwind_begin() being in scm_array_get_handle(), and the scm_dynwind_end() being in scm_array_release_handle().) >> I think you're imagining a clear boundary here where there isn't one. >> If needed, either the scm_dynwind would be inside >> scm_array_get_handle, or it would be inside scm_uniform_vector_read. >> Both of those are public libguile functions, so where's the >> difference? > > The difference is that `scm_array_get_handle ()' is a low-level > function. It may be used, say, in code that passes SRFI-4 vectors to C > that implements "performance-critical" code. Adding consing in there > wouldn't feel right. If you add in " and which can't possibly do a non-local exit " there, I see your point. > Right, I hadn't thought about it, but as you mention, a dynwind in > `uniform-vector-read!' will only affect soft port implementations. With that in mind, do you think we need to solve this now? I think this is low impact, so for now I'm inclined just to raise a bug in Savannah, containing our discussion so far, so that we don't forget it. Regards, Neil