[Guile-commits] GNU Guile branch, branch_release-1-8, updated. release_1-8-6-67-gc7c36fc

[Neil Jerram]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU Guile".

http://git.savannah.gnu.org/cgit/guile.git/commit/?id=c7c36fcf408e792a2eec1b27a9a416829b502c3c

The branch, branch_release-1-8 has been updated
       via  c7c36fcf408e792a2eec1b27a9a416829b502c3c (commit)
      from  0ed755ba5823ecc830466df8f524246ddb0e4ff9 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit c7c36fcf408e792a2eec1b27a9a416829b502c3c
Author: Neil Jerram <address@hidden>
Date:   Tue Jun 30 23:56:40 2009 +0100

    Correction to doc on Accessing Arrays from C
    
    Thanks to Ludovic for the new wording!
    
    * doc/ref/api-compound.texi (Accessing Arrays from C): Correct text to
      reflect the current implementation of scm_array_get_handle and
      scm_array_handle_release - which don't actuall do any dynwind stuff.

-----------------------------------------------------------------------

Summary of changes:
 doc/ref/api-compound.texi |   22 +++++++---------------
 1 files changed, 7 insertions(+), 15 deletions(-)

diff --git a/doc/ref/api-compound.texi b/doc/ref/api-compound.texi
index c551c4d..5ecaca4 100644
--- a/doc/ref/api-compound.texi
+++ b/doc/ref/api-compound.texi
@@ -2342,21 +2342,13 @@ the danger of a deadlock.  In a multi-threaded program, 
you will need
 additional synchronization to avoid modifying reserved arrays.)
 
 You must take care to always unreserve an array after reserving it,
-also in the presence of non-local exits.  To simplify this, reserving
-and unreserving work like a dynwind context (@pxref{Dynamic Wind}): a
-call to @code{scm_array_get_handle} can be thought of as beginning a
-dynwind context and @code{scm_array_handle_release} as ending it.
-When a non-local exit happens between these two calls, the array is
-implicitely unreserved.
-
-That is, you need to properly pair reserving and unreserving in your
-code, but you don't need to worry about non-local exits.
-
-These calls and other pairs of calls that establish dynwind contexts
-need to be properly nested.  If you begin a context prior to reserving
-an array, you need to unreserve the array before ending the context.
-Likewise, when reserving two or more arrays in a certain order, you
-need to unreserve them in the opposite order.
+even in the presence of non-local exits.  If a non-local exit can
+happen between these two calls, you should install a dynwind context
+that releases the array when it is left (@pxref{Dynamic Wind}).
+
+In addition, array reserving and unreserving must be properly
+paired.  For instance, when reserving two or more arrays in a certain
+order, you need to unreserve them in the opposite order.
 
 Once you have reserved an array and have retrieved the pointer to its
 elements, you must figure out the layout of the elements in memory.


hooks/post-receive
-- 
GNU Guile