Path: utzoo!utgpu!watserv1!watmath!att!rutgers!usc!sdd.hp.com!decwrl!ogicse!orstcs!jacobs.CS.ORST.EDU!bailey
From: bailey@jacobs.CS.ORST.EDU (Kirk Bailey)
Newsgroups: comp.sys.transputer
Subject: Re: bugs in LSC
Message-ID: <20095@orstcs.CS.ORST.EDU>
Date: 1 Sep 90 20:50:19 GMT
References: <9008302043.AA02820@cannon.cs.usu.edu>
Sender: usenet@orstcs.CS.ORST.EDU
Organization: Oregon State University - CS - Corvallis
Lines: 52


 
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)