guile-commits
[Top][All Lists]
Advanced

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

[Guile-commits] GNU Guile branch, master, updated. release_1-9-0-35-gdd5


From: Neil Jerram
Subject: [Guile-commits] GNU Guile branch, master, updated. release_1-9-0-35-gdd57ddd
Date: Tue, 30 Jun 2009 22:58:21 +0000

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=dd57ddd5ede6d3d9a736b2b48455fbd87da51e3a

The branch, master has been updated
       via  dd57ddd5ede6d3d9a736b2b48455fbd87da51e3a (commit)
      from  0a94eb002eba6539879f2cddf3e45fb25976af8d (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 dd57ddd5ede6d3d9a736b2b48455fbd87da51e3a
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 b3997ef..7eccb86 100644
--- a/doc/ref/api-compound.texi
+++ b/doc/ref/api-compound.texi
@@ -2358,21 +2358,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




reply via email to

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