"Gabri Gwala" <email@example.com> wrote in message news:firstname.lastname@example.org... > Many thanks to Oliver Woodford and all the other contributors of this > effective strategy. Anyway I would like to submit a potential issue when > using Matlab Parallel Computation Toolbox. In particular i'm trying to use > this scheme inside a parfor, obtaining a segmentation fault while trying > to convert a matlab handle in C++ pointer. > Since this is not a pure Matlab topic, I posted the detailed question on > stackoverflow. > > http://stackoverflow.com/questions/14607109/matlab-c-segmentation-fault-on-parallel-computing-with-c-mex-persistent-obj
I'm not an expert in Parallel Computing Toolbox and referring to C++ objects in MATLAB, but I'm doubtful this will work without significant modification.
Remember that in Parallel Computing Toolbox, workers are separate instances of MATLAB from the client. There's a reason they have the same icon as the MATLAB client session in step 3 of the description of a PARFOR loop:
This means that the value representing a pointer to the C++ object in your client session probably won't point to your C++ object on the workers, and even if it did (for local workers on the same machine) that memory would probably belong to the MATLAB client session (possibly leading to the segmentation violation given in your Stack Overflow posting.)
Think of this like the handle to a figure on the client. When that handle gets passed to the workers, the workers can't use that handle to affect the client's figure window -- it's the client's handle!
If your C++ object had a small amount of state, returning a struct array or cell array from the MEX-file containing the state necessary to reconstitute the object might be an option (since MATLAB knows how to pass structs between the client and the workers) but that kind of defeats the purpose of having a C++ object.