@InProceedings{Teig12, title = "{XCHAN}s: {N}otes on a {N}ew {C}hannel {T}ype", author= "Teig, Øyvind", editor= "Welch, Peter H. and Barnes, Frederick R. M. and Chalmers, Kevin and Pedersen, Jan Bækgaard and Sampson, Adam T.", pages = "155--170", booktitle= "{C}ommunicating {P}rocess {A}rchitectures 2012", isbn= "978-0-9565409-5-9", year= "2012", month= "aug", abstract= "This paper proposes a new channel type, XCHAN, for communicating messages between a sender and receiver. Sending on an XCHAN is asynchronous, with the sending process informed as to its success. XCHANs may be buffered, in which case a successful send means the message has got into the buffer. A successful send to an unbuffered XCHAN means the receiving process has the message. In either case, a failed send means the message has been discarded. If sending on an XCHAN fails, a built-in feedback channel (the x-channel, which has conventional channel semantics) will signal to the sender when the channel is ready for input (i.e., the next send will succeed). This x-channel may be used in a select or ALT by the sender side (only input guards are needed), so that the sender may passively wait for this notification whilst servicing other events. When the x-channel signal is taken, the sender should send as soon as possible -- but it is free to send something other than the message originally attempted (e.g. some freshly arrived data). The paper compares the use of XCHAN with the use of output guards in select/ALT statements. XCHAN usage should follow a design pattern, which is also described. Since the XCHAN never blocks, its use contributes towards deadlock- avoidance. The XCHAN offers one solution to the problem of overflow handling associated with a fast producer and slow consumer in message passing systems. The claim is that availability of XCHANs for channel based systems gives the designer and programmer another means to simplify and increase quality." }