From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Dirk Herrmann Newsgroups: gmane.lisp.guile.devel Subject: Re: Stack unwinding for C code Date: Fri, 02 Jan 2004 12:45:12 +0100 Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Message-ID: <3FF559C8.2040702@dirk-herrmanns-seiten.de> References: <87y8sz5kio.fsf@zagadka.ping.de> <87ptea40wu.fsf@zagadka.ping.de> <87brppkft6.fsf@zagadka.ping.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1073053199 7317 80.91.224.253 (2 Jan 2004 14:19:59 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 2 Jan 2004 14:19:59 +0000 (UTC) Cc: guile-devel@gnu.org, Neil Jerram Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jan 02 15:19:56 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AcQ9b-0001BQ-00 for ; Fri, 02 Jan 2004 15:19:56 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcQuC-000214-Bh for guile-devel@m.gmane.org; Fri, 02 Jan 2004 10:08:04 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AcQCW-0006Jg-Lv for guile-devel@gnu.org; Fri, 02 Jan 2004 09:22:56 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AcQ1k-0005Le-PY for guile-devel@gnu.org; Fri, 02 Jan 2004 09:12:20 -0500 Original-Received: from [212.227.126.171] (helo=moutng.kundenserver.de) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AcOh7-0006gJ-Cs for guile-devel@gnu.org; Fri, 02 Jan 2004 07:46:25 -0500 Original-Received: from [212.227.126.207] (helo=mrelayng6.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1AcNjc-0003cG-00; Fri, 02 Jan 2004 12:44:56 +0100 Original-Received: from [80.131.42.83] (helo=dirk-herrmanns-seiten.de) by mrelayng6.kundenserver.de with asmtp (Exim 3.35 #1) id 1AcNjc-00068A-00; Fri, 02 Jan 2004 12:44:56 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821 X-Accept-Language: de, en Original-To: Marius Vollmer In-Reply-To: <87brppkft6.fsf@zagadka.ping.de> X-Enigmail-Version: 0.76.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:494e3e4d1bf8dc247959c49e6f1f4215 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.2 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 Xref: main.gmane.org gmane.lisp.guile.devel:3154 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:3154 Marius Vollmer wrote: >I see. Hmm. I have no ideas (yet) about what to do about >SCM_DEFER_INTS, etc. But you are right, we should have a plan for >bringing all things that are related to the dynamic context together. >So what about separating the API further: there would be only >scm_begin_frame and an additional function scm_prevent_rewind (or >scm_prevent_reentry?) could be used like > > scm_begin_frame (); > scm_prevent_rewind (); > ... > scm_end_frame (); > I like this style of interface for its simplicity. But, I am somewhat confused since in your proposal below you don't suggest this style of interface, but instead describe scm_begin_frame as receiving an additional argument with flags. I wouldn't prefer any of the two solutions, but I am currently not sure what you actually suggest - especially since in the example given below you don't pass any argument to scm_begin_frame. >Sometimes, it is necessary to perform cleanups when the unwinding >happens. Frequently, dynamically allocated temporary data structures >need to be deallocated, for example. > If this document was to be reused in the documentation later, we should given an example here. >- C Function: void scm_begin_frame (int flags) > > Starts a new frame and makes it the 'current' one. FLAGS determines > the default behavior of the frame. For normal frames, use 0. This > will result in a frame that can not be reentered with a captured > continuation. See below. > > The frame is ended either implicitly when a non-local exit happens, > or explicitly with scm_end_frame. > If this style of API is used (that is, passing a 'flags' argument to scm_begin_frame instead of having separate functions like scm_prevent_rewind and similar), then I suggest to use an enumeration type with all possible flags instead of an int type. This improves both type safety and readability of the code using scm_begin_frame. The same applies to the 'explicit' argument to scm_on_unwind and scm_on_rewind. >- C Function: void scm_on_unwind (void (*func)(void *), void *data, > int explicit) > > Arranges for FUNC to be called with DATA as its arguments when the > current frame ends implicitly. If EXPLICIT is non-zero, FUNC is > also called when the frame ends explicitly. > It is a nice coincidence that 'free' matches the void (*func) (void *) signature, especially since free will probably be one of the most frequently used functions with scm_on_unwind. fclose, however, does not match and is another candidate that may be commonly used. Unfortunately it wouldn't be standard conforming to just cast fclose to match the signature. I suggest that (in addition to the generic scm_on_unwind) for a limited set of common functions we provide specialized scm_on_unwind_xxx functions, like: scm_on_unwind_free (void *data, int explicit); // could simply be #defined to scm_on_unwind scm_on_unwind_fclose (FILE* fp, int explicit); // on some architectures this may also safely be #defined to scm_on_unwind // maybe there are other typical cleanup functions... Then, scm_on_unwind_free could either simply be #defined to scm_on_unwind, or - if it brings some performance and code size benefit to avoid passing the additional argument - provided as a special implementation. On some architectures it may also be an option to just #define scm_on_unwind_fclose to scm_on_unwind. Best regards Dirk Herrmann _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel