From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Subject: Re: [9fans] select()
From: "Russ Cox" <rsc@plan9.bell-labs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Message-Id: <20001116224334.5EC75199E6@mail.cse.psu.edu>
Date: Thu, 16 Nov 2000 17:43:15 -0500
Topicbox-Message-UUID: 2c2e44c6-eac9-11e9-9e20-41e7f4b1d025

	In http://plan9.bell-labs.com/sys/doc/9.html, there's a hint that Plan 9's
	design avoids some of the nastiness with select() here:

	    Compare this to the UNIX select system call: select applies only
	    to a restricted set of devices, legislates a style of
	    multiprogramming in the kernel, does not extend across networks,
	    is difficult to implement, and is hard to use.

	Would someone be so kind as to elaborate? It looks like select() is
	implemented very much like BSD select() in the APE.

Select in the APE is implemented entirely at user level,
with no help from the kernel.  It continually calls sleep(100)
and then checks for input.  Select on most Unix systems
is a system call, which requires the kernel to do all that 
and usually more.  Further, since select requires that at most
one of the reads succeeds, it is very hard to implement once
you have file systems coming from somewhere other than
local resources (e.g., any network file system).  It also often
makes for awkward program structure.

The passage you quote is, I believe, arguing that Alef's
style of multiprogramming is a better solution than select,
not that Plan 9 makes select easier to implement.  Select is
inherently hard to implement because of its specification.
Rob argues the benefits of a precursor to the Plan 9 style
of multiprogramming more extensively in
http://plan9.bell-labs.com/cm/cs/doc/89/1-a.ps.gz.

Russ