From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Fri, 15 Aug 1997 17:22:30 +0100
From: forsyth@caldo.demon.co.uk forsyth@caldo.demon.co.uk
Subject: [9fans] plan9 extensions
Topicbox-Message-UUID: 5ee27aa0-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19970815162230.94ufN6EiS-U42yGwbc9rDHPtg7S62WVCFYP2YAk3JbI@z>

>>Has Brazil (or any future development) at Lucent given any thought to this
>>matter?  Your insights and suggestions are most welcome.

BSD style readv/writev are arguably just optimisations (although they
usually boil down to a copy inside the kernel), and thus cause no
serious reasoning problems.  asynchronous i/o, like signals/notes and
those unbelievable `call back' functions, reintroduce the Interrupt,
which is bad for reasoning and certainly for the morale of subsequent
maintainers of an application.  i'd put my effort into improving the
efficiency of what is there, rather than going back to un-reasonable hacks.

it might be of interest that in Limbo/Inferno one can do something like:

input(c: chan of array of byte)
{
	for(;;){
		a := array [N] of byte;
		n := sys->read(fd, a, len a);
		if(n <= 0){
			c <-= nil;
			break;
		}
		c <-= a[0:n];	# slice to n bytes
	}
}

and some other process can do

	c := chan of array of byte;
	spawn input(c);
	while((a := <-c) != nil)
		dosomethingwith(a);

or pass a along another channel to another process, and so on,
the point being that transmission is by reference (you can get
your garbage collector to help you with this one).

Sys->file2chan is even cooler: it eliminates copying between the system
and the file server, though not between system and file client, because
that isn't safe.