Known Bugs

Slave Matlab sessions fail to start
If the slavedislay setting is specified incorrectly, slaves matlab sessions may not
start correctly when using ssh/rsh or jr spawn methods (does not apply to forked slaves)
SOLUTION:
Disable slave graphics, by setting slavedislay to 'none'. This means slaves cannot create figures etc (who wants to do that anyway?).

Slaves die when break pressed
Sometimes pressing break in the middle of a pfor
computation makes some of the slaves
die. SOLUTION: Dont press break in the middle of a
pfor computation, or alternatively restart the
parallel machine.

MOSIX slaves return home
MOSIX: Some Matlab function calls forces the matlab
slaves to migrate home, which can be catastrophic
if you have spawned a large number of them. I have
no solution to this problem, I think it is because
Matlab uses mmap() to access files in a certain
way which triggers MOSIX to force the process
home.

Forked slaves dont recognize changed m-files
When spawning slaves with the fork method, the
slaves no longer recognize changes to .m files or
mex files in the search path. This is because the
forked slaves never actually return from the pinit
function call (they are as I said, forked!) they
simply enter a command receiving mode. Slaves
spawned with rsh are different: They are actually
Matlab engines which return to the main Matlab
kernel every once in a while. SOLUTION: Restart
the parallel machine if the forked slaves need to
recognize any changes made to m-files or
MEX-files, or alternatively, use the rsh/ssh/jr
method for spawning slaves.

If you have found additional bugs please
mail me a description of the problem