Changelog for plab
1.11
May 5, 2002
===============================================================================
Just a small update to correct a bug that caused plab not to compile on
Redhat 7.1, a compile error "DONT_KNOW_CLK_TCK_OR_HZ"
1.09
Jan 25, 2000
================================================================================
Things should be ok now with matlab 6.0.
Ooops, the setsockopt thing introduced in 1.07 gaves problems with Linux.
Sun users need to specify this in plab.h by "#define SUNOS" if they have problems
like:
"vm.cpp", line 131: Error: Formal argument 4 of type const char* in call
to setsockopt(int, int, int, const char*, int) is being passed int*.
1.07
Nov 20, 2000
================================================================================
Correction of call to setsockopt in vm.cpp. This caused compilation
problem on Sun with Workshop compiler 4.2 (Bernd Markgraf)
1.06
Nov 19, 2000
================================================================================
Initial version released on the web.
Known Bugs:
Due to some new "feature" in Matlab 6 and up, the evaluation of a string
expression has been made a lot less efficient. The time it takes to
repeatedly evaluate a simple expression grows for each call (!!)
I have found no workaround for this, except use the good old Matlab 5.3...
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