Re: array handles and non-local exits

[Ludovic Courtès]

Hi,

"Neil Jerram" <address@hidden> writes:

>>>> 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().)

Yes.

>>> 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.

Exactly.

>> 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.

I submitted this bug:

  https://savannah.gnu.org/bugs/index.php?24292

(Oops I forgot "and dynwinds" in the bug title...)

I would suggest that we drop that mention of dynwinds from the manual.

Thanks,
Ludo'.