guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Stack unwinding for C code


From: Dirk Herrmann
Subject: Re: Stack unwinding for C code
Date: Fri, 02 Jan 2004 12:45:12 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030821

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]