[9fans] plan9 extensions

[9fans] plan9 extensions

[forsyth]

>>including communications and scsi subsystems.  Some measurements indicate

i made a few changes quite some time ago to encourage more concurrency of i/o
inside the scsi interface in the cpu/terminal kernel.  those changes help, but no doubt
much more could be done.  my scsi tape began to stream well and that was all i needed!

[9fans] plan9 extensions

[Dan]

The synchronous copy everything model in plan9 might be extended for
performance reasons to include such primitives as asynchronous i/o and
pre-formatted vector read/write operations.  Has any thought been given
in the plan9 community as to a generic interface for asynchronous i/o?
Although it is trivial to implement efficient asynchronous i/o in a particular
driver perhaps it would be best to have a generic interface for all i/o,
including communications and scsi subsystems.  Some measurements indicate
that utilizing light weight processes for achieving asynchronous behavior
may not have the desired performance characteristics.

Has Brazil (or any future development) at Lucent given any thought to this
matter?  Your insights and suggestions are most welcome.
danc
Dan L. Clark       dlc@ncube.com    503/531-6432
nCUBE, 1825 NW 167th Place, Beaverton, OR  97006

[9fans] plan9 extensions

[forsyth]

>>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.