2008/9/16 Ludovic Courtès <[EMAIL PROTECTED]>:
>
> 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
