From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <d770e27d2897bc7e3f0638d36f554c27@vitanuova.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Channel casting
From: rog@vitanuova.com
In-Reply-To: <3100726675a9ffcb9f2eefc78956dba1@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Wed, 21 May 2003 18:27:19 +0100
Topicbox-Message-UUID: b5a1717c-eacb-11e9-9e20-41e7f4b1d025

> For the case you describe, the client typically
> sends a (request, return-channel) pair and
> then recvs from the return channel, which is
> private to that client.

note that if clients adhere correctly to protocol, then it's not
strictly necessary to allocate a new channel each time.

to modify russ's examples:

an echo server:
	srvchan := chan of int;
	srvreplychan := chan of int;
	for(;;){
		n := <-srvchan;
		srvreplychan <-= n;
	}

	echothread(srvchan, replychan: chan of int)
	{
		for(i:=0;; i++){
			srvchan <-= i;
			j := <-replychan;
			sys->print("sent %d, got %d\n", i, j);
		}
	}

	spawn echothread(srvchan, srvreplychan);
	spawn echothread(srvchan, srvreplychan);
	spawn echothread(srvchan, srvreplychan);
	spawn echothread(srvchan, srvreplychan);

since we're using synchronous (unbuffered) channels, and clients
always write, then read, the server is guaranteed to be writing back
to the same client.

sometimes this makes things simpler; other times, sending a reply
channel makes more sense (particularly when the kind of reply might
depend on the particular request).

  cheers,
    rog.