Re: array handles and non-local exits

[Neil Jerram]

2008/9/16 Ludovic Courtès <address@hidden>:
>
> If `get_handle ()' creates a dynwind that ends in `release_handle ()',
> then code like the following will no longer work as expected:
>
>  scm_dynwind_begin ();
>  scm_dynwind_unwind_handler ();
>  scm array_get_handle ();
>
>  ...
>
>  scm_dynwind_end ();
>  scm_array_release_handle ();
>
> Perhaps that's what is implied by the manual's wording but I find it a
> bit tricky.

Yes, that definitely is what the manual means by "properly nested" -
but I also agree that it is a bit tricky.

>>> and (2) I don't know of any other function that does a dynwind behind
>>> the scenes (IOW, let's not break the "rule of least surprise").
>
> I meant "I don't know of a function that does a `dynwind_begin'
> *alone*" (of course there are plenty of functions that do
> `dynwind_begin' + `dynwind_end').

Yes, I see what you mean now.  (The scm_dynwind_begin() being in
scm_array_get_handle(), and the scm_dynwind_end() being in
scm_array_release_handle().)

>> I think you're imagining a clear boundary here where there isn't one.
>> If needed, either the scm_dynwind would be inside
>> scm_array_get_handle, or it would be inside scm_uniform_vector_read.
>> Both of those are public libguile functions, so where's the
>> difference?
>
> The difference is that `scm_array_get_handle ()' is a low-level
> function.  It may be used, say, in code that passes SRFI-4 vectors to C
> that implements "performance-critical" code.  Adding consing in there
> wouldn't feel right.

If you add in " and which can't possibly do a non-local exit " there,
I see your point.

> Right, I hadn't thought about it, but as you mention, a dynwind in
> `uniform-vector-read!' will only affect soft port implementations.

With that in mind, do you think we need to solve this now?  I think
this is low impact, so for now I'm inclined just to raise a bug in
Savannah, containing our discussion so far, so that we don't forget
it.

Regards,
        Neil