Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!oberon!sm.unisys.com!aero!venera.isi.edu!raveling
From: raveling@vaxb.isi.edu (Paul Raveling)
Newsgroups: comp.os.misc
Subject: Re: Asynchronous I/O (was generalized bigotry)
Message-ID: <7397@venera.isi.edu>
Date: 1 Feb 89 04:05:47 GMT
References: <19@xenlink.UUCP> <225800108@uxe.cso.uiuc.edu> <2075@scolex> <7304@venera.isi.edu> <2851@ficc.uu.net>
Sender: news@venera.isi.edu
Reply-To: raveling@vaxb.isi.edu (Paul Raveling)
Organization: USC-Information Sciences Institute
Lines: 46

In article <2851@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:
>
>One thing, though... passing structures around isn't so cool.

	I agree within this context (oops, I already edited that part of
	the message out), though I have actually done this on occasion.
	What I'd REALLY like is a language feature for multiple
	return values... it might look something like:

	(completion_status, bytes_actually_read, updated_buffer_pointer) =
		Read (file, buffer, nbytes);
			** or **
		WaitFor (READ_EVENT_ID /* for prior ARead */);

	In fact, that example is what we did in EPOS for block input,
	where we roughly mimiced TENEX's SIN (string input) function.
	The catch was that we did it in assembly language.

	It turns out that sensible machine designers provided a great
	feature to help with this sort of thing -- a register set.
	On a decent machine there are at least as many registers as
	there are parameters for functions such as this, and returned
	info is an even easier fit.  Using the registers is fast,
	no memory allocation is needed for parameters in registers,
	and the hardware supplies stack operations to save and restore
	them on opposite sides of context switches.

	With multiple return values it's easier to avoid overloaded
	return values.  With a separate status code and count of
	bytes read, there's no need for special cases such as byte
	counts or "character" values of -1 or 0.  In EPOS virtually
	ALL system calls issued a status (return) code that the caller
	could feed to a function something like perror; 0 was the
	universal code for "no error".


	It's possible to do this sort of thing in a fairly C-like
	language.  BLISS-11 even did a good job of handling parameters
	in registers.  Seems like it would be both fun and valuable
	to fuse some of these notions for languages and system interfaces
	into a coherent scheme.


---------------------
Paul Raveling
Raveling@vaxb.isi.edu