[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: array handles and non-local exits

From: Ludovic Courtès
Subject: Re: array handles and non-local exits
Date: Thu, 18 Sep 2008 10:15:59 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux)


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


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

I submitted this bug:

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

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]