Re: some notes about mex support in Octave

[Paul Kienzle]

On Jul 8, 2006, at 12:24 PM, John W. Eaton wrote:

> On  8-Jul-2006, Paul Kienzle wrote:
>
> | Using fortran_vec as I suggested will probably force a copy.  Given
> | the above semantics I would be tempted to use data() and cast away
> | the const so that simply querying an input argument to a function
> | doesn't force a copy.  This may lead to unexpected behaviour, e.g.,
> | by mutating existing variables but that is a documented property of
> | the mex interface so caveat emptor.
>
> That's all fine except that the documentation gives the green flag to
> things like this:
>
>   double *old_data;
>   double *new_data;
>   int N;
>   int M;
>   mxArray *some_array = mxCreateDoubleMatrix (0, 0, 0);
>   ...
>   get values for M, N
>   ...
>   mxSetM (some_array, M);
>   mxSetN (some_array, N);
>
>   old_data = mxGetPr (some_array);
>   mxFree (old_data);
>
>   new_data = mxCalloc (sizeof (double), M*N);
>   mxSetPr (some_array, new_data);
>
> If the value returned from mxGetPr is really the internal data from a
> Matrix object and the user deletes it, then bad things happen.
>
> Or can we get away with this if we ensure that mxFree only deletes
> data allocated by the mxMalloc, mxCalloc, and mxRealloc functions and
> just ignores everything else so that it will be deleted as before (by
> the Matrix class destructor, when there are no more references to it)?

We already need to track allocations because working storage that
is allocated but not returned or made persistent is automatically
cleaned up when the function returns.  Checking this list inside
mxFree is not a problem.  In practice it won't happen since it would
be wrong for a mex file to delete a rhs mxArray.

> Another tricky case is persistence.  If a mex file makes a value that
> comes from Octave persistent, what happens?  I guess we have to grab
> an extra reference to the value so that it won't go away while the
> persistent flag is set.

Again I don't think this will happen.  Persistence is for working
storage that you keep in a static pointer because you don't want
to reallocate it on every call to the function.  It is not something
you need for a rhs or lhs mxArray.

In this case and the case above we can issue warnings when the
operations are attempted but in fact do nothing.  If the warnings
appear then clearly my assumptions are wrong.

> So yes, avoiding copies will be much more complex.  That's why I'm
> inclined to do the simple but less efficient thing first.

No argument there, though I think a hybrid approach will not be
that complex.  In particular, I'm not sure a deep copy on cell
arrays or structures is warranted.

- Paul