This defines the interface for reading from object channels.
ChannelInput variables are used to hold channels that are going to be used only for input by the declaring process. This is a security matter -- by declaring a ChannelInput interface, any attempt to output to the channel will generate a compile-time error. For example, the following code fragment will not compile:
void doWrite (ChannelInput c, Object o) { c.write (o); // illegal }When configuring a CSProcess with input channels, they should be declared as ChannelInput (or, if we wish to be able to make choices between events, as AltingChannelInput) variables. The actual channel passed, of course, may belong to any channel class that implements ChannelInput (or AltingChannelInput).
The Object returned can be cast into the actual class the reader process expects. If the reader can handle more than one class of Object (similar to tagged protocols in occam), checks should be made before casting.
void doRead (ChannelInput c) { c.read (); // clear the channel }
void doRead (ChannelInput c) { Boolean b = (Boolean) c.read(); // will cause a ClassCastException // if read does not return a Boolean ... etc. }
void doRead (ChannelInput c) { Object o = c.read (); if (o instanceof Boolean) { System.out.println ("Boolean: " + (Boolean) o); } else if (o instanceof Integer) { System.out.println ("Integer: " + (Integer) o); } else { System.out.println ("Unexpected Class: " + o); } }
Methods inherited from class | Name |
---|---|
interface Poisonable |
poison |
The call that signifies the end of the extended rendezvous, as begun by endRead. This function should only ever be called after endRead, and must be called once (and only once) after every endRead call.
Read an Object from the channel.
Begins an extended rendezvous read from the channel. In an extended rendezvous, the communication is not completed until the reader has completed its extended action (in JCSP, this means that the writer has to wait until the reader calls the corresponding endExtRead function). The writer notices no difference in the communication (except that it usually takes longer). You must call endRead at some point after this function, otherwise the writer will never be freed and deadlock will almost certainly ensue. You may perform any actions you like between calling beginExtRead and endRead, including communications on other channels, but you must not attempt to communicate again on this channel until you have called endExtRead. An extended rendezvous may be used after the channel's Guard has been selected by an Alternative (i.e. it can be done in place of calling read).