Re: array handles and non-local exits

[Andy Wingo <wingo@pobox.com>]

Hey folks :)

On Thu 18 Sep 2008 11:17, "Neil Jerram" <neiljerram@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/