Path: news.mathworks.com!not-for-mail
From: <HIDDEN>
Newsgroups: comp.soft-sys.matlab
Subject: Re: copy-on-write with MEX files
Date: Sat, 29 Nov 2008 01:20:19 +0000 (UTC)
Organization: Universit&#228;t Heidelberg
Lines: 14
Message-ID: <ggq5cj$c68$1@fred.mathworks.com>
References: <g68b41$cu8$1@fred.mathworks.com>
Reply-To: <HIDDEN>
NNTP-Posting-Host: webapp-02-blr.mathworks.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Trace: fred.mathworks.com 1227921619 12488 172.30.248.37 (29 Nov 2008 01:20:19 GMT)
X-Complaints-To: news@mathworks.com
NNTP-Posting-Date: Sat, 29 Nov 2008 01:20:19 +0000 (UTC)
X-Newsreader: MATLAB Central Newsreader 869888
Xref: news.mathworks.com comp.soft-sys.matlab:503729


Dear Matt!

> I'm trying to understand if there is a difference in the 
> way copy-on-write is implemented for MEX functions as 
> compared to Mfiles.

Look into the file matrix.h (in <matlabroot>\extern\include\). There you find the code for array_access_inlining, which shows the implementation of a Matlab array.
Besides the obvious fields as pointer to real and imaginary part of the data, number of dimensions and size of an element, you find a bunch of flags and several pointers to void called "reserved", "reserved1" etc.
It might be easy to find out, which field is the vector keeping the dimensions, the class and the perhaps the name of the array. But a reverse-engineering of the bunch of flags wil be impossible and as far as I know: this might be conflicting with the terms of use.

Sometimes one really needs passing variables by reference to a MEX file and changing the original memory - i.e. if your data occupy 50% of your available RAM: Then just create a new class, which works with memory persistently stored in a MEX file: see mexMakeMemoryPersistent. Then the object does not contain the data itself, but just a pointer to it and passing by reference is performed implicitly. A drawback is, that the complete processing must be done in MEX functions.

Kind regards, Jan