Re: [Pika-dev] Guile FFI: resizable vector problem

[Tom Lord]

    > From: address@hidden

    > I think you misunderstood the point I was trying to make: I was not
    > discussing the specific choices that may be currently embodied in the
    > pika implementation, I was suggesting and justifying a possible way of
    > designing abstractions that are robust in the face of concurrency
    > while incurring only minimal overhead.

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

The ref, set, and resize operations surely need to be consistently
serializable.   In addition, I plan to add the explicit locking
protocol I described to make it possible to add to the list of
serializable vector operations.   

I don't see any way that this precludes your implementation technique,
but now it sounds if you are saying that you do.   If so, can you
please say more clearly how?


    > For example, you could easily make your abstractions robust with
    > respect to concurrency by means of a single global lock, thus
    > effectively sequentializing all operations, but that would not be a
    > very good choice.  You could improve things by using one lock per
    > mutable datastructure, thus sequentializing operations only per
    > datastructure.  Finally, you could additionally rely on the argument
    > that I outlined (assuming that it can be proven correct) to require
    > even less locking.

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, 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.  A very large part of the
point of the Pika Scheme project is to get these APIs right so that in
the future, the widest variety of implementation techniques is
available to us (without changing the API).

So the question in my mind is whether or not you are saying that, for
some reason, the API should not include ref, set, and resize
primitives which are promised to be serializable --- or if you think
there is a better alternative to the locking operations for creating
additional serializable primitives.

-t