Hey folks :) On Thu 18 Sep 2008 11:17, "Neil Jerram" <neiljer...@googlemail.com> writes:
> In my view, this part is still useful: > > "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 (see Dynamic Wind): a call > to scm_array_get_handle can be thought of as beginning a dynwind > context and 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." I'm hacking on this code right now, and have come to think that scm_array_handle_release is superfluous. It shouldn't protect against concurrent modification of the data, as that should be done with user-implemented mutexen. It obviously doesn't do anything now -- and really, it doesn't have anything to do. I can't think of a /supported/ modification of an array that will leave a pointer to the elements invalid -- i.e. we have no truncation ops that I know of. The pointer will always be valid as long as we have a reference to the array itself (which we do, on the stack, in the scm_t_array_handle). Andy -- http://wingolog.org/
