Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!ceres.physics.uiowa.edu!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!rutgers!uwm.edu!wuarchive!usc! samsung!know!mips2!bull.bull.fr!corton!mcsun!ukc!ox-prg!news Newsgroups: comp.sys.transputer Subject: Re: Anarchic protocol ANY (occam2) Message-ID: <1758@culhua.prg.ox.ac.uk> From: Geraint.Jones@comlab.oxford.ac.uk Date: 19 May 91 15:17:39 GMT Reply-To: geraint@prg.ox.ac.uk (Geraint Jones) References: <9105152020.AA15174@theory.TN.CORNELL.EDU> Organization: Oxford Parallel Reality, UK Lines: 32 In article llw@ghostwheel.eng.yale.edu (Louis L. Whitcomb) writes (about CHAN OF ANY): >-> >-> The behavior of software and hardware channel communication in >-> in the Inmos OCCAM2 compiler is not identical. >-> ... >-> Curiously, you'll find that your code sample will run fine in a >-> configuration where the channel "to.p2" is a hard link, but not when >-> it is a soft link. Try it. The implementation of channel >-> communication in OCCAM2 behaves differently on hard and soft channels. >-> ... >-> The moral of the story: If you use OCCAM2, use explicit protocols - >-> even though they are cumbersome and restrictive. It is hard to track >-> down bugs without them. >-> >-> Note that ihe implementation of channel communication in the newly >-> released INMOS ANSI C compiler does *not* suffer from this curious >-> design flaw. I'm not sure what you think is the design flaw: the programs in question are not guaranteed to work (by the occam2 Reference Manual). The only `unexpected' behaviour is that Inmos' occam2 compiler happens to produce code which makes this invalid non-program do what its author expected in case the communication is on hard channels. It is _very_ hard to guarantee that all incorrect programs do something unexpected; the usual contract with a language implementor is that all correct programs should only do the expected. The moral extracted from the story is fine, though. Think of CHAN OF ANY as one of those horrible messes that you end up having to use when the other end of the channel is attached to something other than an occam process whose behaviour you are able to determine. g