Re: Guile FFI: resizable vector problem

Tom Lord <lord-1tv/[email protected]> writes:

> But the point is: I don't see any way in which your proposed
> implementation technique suggests a need to change the APIs.

it doesn't and I never suggested that it did :-)  I really wasn't
discussing the API, but rather ways to approach the implementation of
non-atomic operations that need to preserve the appearance of
atomicity.  I only intended it as a very modest suggestion to keep in
mind.

> One doesn't have to use (explicit) locking at all to invoke the ref,
> set, and resize primitives.   One _may_ use the explicit locking
> interface to add to the list of primitives that are serializable.

of course not: they are abstractions which should observationally
behave as if they were atomic.  I was discussing what possible minimal
use of locking the implementation of such primitives might require,
and why one might be able to get away with less locking than it might
seem at first.  The "why" was my main point, the "how" was an
illustration.

>     > Of course, whether pika's design makes it possible to take advantage
>     > of such an option or not, is a separate question :-)
>
> No, it's not -- it's the central question.

it's definitely an important question, but nonetheless separate from
the one I was considering.  But of course, I fully agree with you that
abstractions should preferably be designed in such a way as to not
preclude useful and desirable optimizations :-)

Cheers,

-- 
Dr. Denys Duchier
Équipe Calligramme
LORIA, Nancy, FRANCE