From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
Date: Fri, 14 Jul 2000 09:20:20 +0000
From: Wesley Felter <wesf@cs.utexas.edu>
Message-ID: <B593FDF2.CBBA%wesf@cs.utexas.edu>
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
References: <200007121443.KAA25866@cse.psu.edu>, <200007121455.KAA01408@egyptian-gods.mit.edu>
Subject: Re: [9fans] Re: Any significant gotchas?
Topicbox-Message-UUID: dda94dd2-eac8-11e9-9e20-41e7f4b1d025

in article 200007121455.KAA01408@egyptian-gods.mit.edu, Greg Hudson at
ghudson@mit.edu wrote on 7/12/00 10:13 AM:

>> Maybe Plan 9 can do this cleaner, maybe not, the trick is it is a
>> very mutable system that isn't UNIX and offers you the opportunity
>> to look at things in a different way.
> 
> Just to relay one such idea, I'm told Solaris has introduced a
> /dev/poll in recent versions.  (Though it doesn't happen to be in
> Solaris 7, the most recent version I have access to at the moment.)
> The idea seems fairly straightforward and should scale quite well.

The Linux Scalability Project has /dev/poll patches for Linux and a paper
comparing poll(), /dev/poll, and queued realtime signals (which are really
more like event queues than signals IMO).

http://www.citi.umich.edu/projects/linux-scalability/index.html

The ScalaServer project proposed another event queue API, which may be
similar to the one recently adopted in FreeBSD.

http://www.cs.rice.edu/CS/Systems/ScalaServer/index.html

SGI has a very lightweight threads library, although I'm skeptical that it
can beat the event-driven model.

http://oss.sgi.com/projects/state-threads/

Wesley Felter - wesf@cs.utexas.edu