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