Re: Removing scm_vector_set_length_x ?

[Dirk Herrmann]

On 11 Oct 2000, Marius Vollmer wrote:

> > I have removed all calls to scm_vector_set_length_x from libguile.
> > Thus, the function could now be deprecated or removed immediately.
> > Changing the length of an existing vector is something that should
> > not be supported by the API, IMO.
> 
> Why not?  I think it would be convenient thing to have, even on the
> Scheme level.  What is strange about it?

It's a problem with threading:  Resizing a vector means to get a new
memory region of the appropriate size, copying the contents into it,
changing the vector object to point to the new region and then deleting
the old region.  (Even when using scm_must_realloc the steps performed
are essentially the same.)

And now to the problem:  How do you use a vector?  You typically extract
the pointer to the elements and work on those, while still making sure
that the vector object is gc protected.  But, if resizing of vectors is
allowed, this does not work anymore:  While you are using the pointer to
the elements (say, in a loop), this pointer suddenly becomes invalid,
because some other thread just resized your pointer :-(  In fact, the
possibility to resize a vector means, that you would have to use a mutex
for every access to a vector's contents.

On 11 Oct 2000, Michael Livshin wrote:

> [...]  in
> Common Lisp, they have simple vectors and adjustable vectors, with
> resizing available only for the adjustable variant.  that way, people
> are free to implement the simple variant without any indirection.

With such a distinction, the need for using a mutex would be restricted to
the adjustable vector variant.  But, if these vectors behave equally on
the scheme level (i. e. adjustable vectors fulfill vector?), then, still,  
all C code that uses vectors has to be changed to use the mutex if given
an adjustable vector.

I doubt that this is worth the effort.  It is always easy to create a new
vector of the desired size and copy the contents of the old one.  The only
benefit that resizable vectors might have is, that in certain
circumstances scm_must_realloc could reuse the existing memory and just
append to it.  That's all from a performance point of view.  The other
benefit is not really a benefit, namely to change the characteristics of
an existing object.  I don't think it's a good thing if
  (= (vector-length v) (begin (f v) (vector-length v)))
is not guaranteed any longer, but depends on what f happens to do with v.

Best regards
Dirk