scott@CANNON.CS.USU.EDU (Scott Cannon) (08/31/90)
The following bugs/quirks/features in Logical Systems C were recently documented by a group of graduate students. I've not verified them so some may not be completely valid or simply improper use of the library. Has anyone else seen these problems? I believe the version was 88.4 and these bugs may have been fixed in later versions. The bugs were noted while developing software on a CSA transputer board with 4 T800 nodes @ 1MB ea. using a boo4 and hosted by a HP AT-class PC: A. Multiple ChanIn() calls don't receive the exact number of bytes sent in the corresponding ChanOut() call. For example, a 4-byte ChanOut() read with a 1-byte ChanIn() followed by a 3-byte ChanIn() will drop the first byte and may produce garbage in the last byte. SOLUTION: use ChanIn() calls of the same number of bytes OR multiple 1-byte ChanIn() calls also seem to work. B. According to documentation, ProcAlt() blocks the calling process until one of the channels in its parameter list is ready. Instead, ProcAlt() immediately returns with an index into the NULL channel in its parameter list if no channel is ready. SOLUTION: put a while loop around any ProcAlt() calls which checks for the NULL index. C. ChanOutTimeFail() should clear the output channel and return control to the calling program if it is unable to send the data in the given time. The function returns control, but sometimes leaves the first byte it was trying to send in the channel. SOLUTION: have any such calls send a header of some sort instead of actual data. On the receive side, have the ChanIn() call ingore any headers that may have piled up in the channel. D. Garbage data is sometimes sent up the boot channels when a child process ends. SOLUTION: always end a process with ProcStop() rather that simply falling through. E. fprintf() refuses to write a 0 byte to a file even if the file was opened with mode "wb". SOLUTION: use fwrite(). Scott R. Cannon, Ph.D. Utah State Univ. scott@cannon.cs.usu.edu
bailey@jacobs.CS.ORST.EDU (Kirk Bailey) (09/02/90)
The following notes address the points Scott Cannon raised. I'm posting it here
instead of just sending him an EMAIL message since other folks might also be
interested in the resolution of his questions:
Point A - The fact that the sending and recieving message length must be
the same is part of the basic Transputer architecture when "soft" channels are
being used. See the documentation for the "ChanIn" library routine for a more
detailed discussion of "soft" -vs- "hard" channels. Also note that with the
upcoming H1 series the capability for asynchronous protocols using "hard"
channels is not present so use of this facility is not recommended for
application level code.
Point B - The problem Scott describes with ProcAlt is unknown to me, I
would be happy to look into it given an example program which demonstrates the
problem. Some possibilities which come to mind are: incorrectly initialized
channels, mixed priority "race" conditions when setting up the ALT, etc.
Point C - The problem with ChanOutTimeFail is again a reflection of the
underlying Transputer architecture. Briefly, the first byte of a message is
part of the synchronization mechanism used by the channel "micro-engine".
Whether the recieving process reads the first byte depends on exactly how
(and when), the hardware communication failure occurs. The solution Scott
mentioned is workable, but others exist also. Inmos has an application note
available which goes into great detail on this issue titled "Extraordinary
use of Transputer Links" or something similar.
Point D - The problem with "exited" child processors sending data out
the original bootstrapping link is due to the fact that "exit" on the root
node must send a message to the host during shutdown to allow the host server
to finish up and shut down in turn. If the programs for the non-root nodes
are linked with "_ns_main" (non-server version of "_main"), this problem will
stop. See the documentation for more information (note that the 89.1 doc
goes into more detail on this point than 88.4 did). The solution Scott used
of calling ProcHalt/Stop is satisfactory also.
Point E - The problem with writting a "\0" from printf probably has to
do with the MSC library routines the server uses under MS-DOS to actually
implement the host portion of the "printf" call. As we are converting over to
another host compiler/library for the next version of our server I will post a
request with our programmers to look into this on the new version and see if
the library has been corrected. If not we can probably find a way to
simulate the same effect...
Cheers,
Kirk Bailey
Logical Systems
P.O. Box 1702
Corvallis, OR 97339
(503) 753-9051
(503) 753-4629 (fax)