[From nobody Sat Mar 13 18:14:24 2010
Return-Path: <srushing@ironport.com>
Received: from smtp.ironport.com (nat.ironport.com [63.251.108.100])
	by trixie.triqs.com (8.11.6/8.11.6) with SMTP id g5CI2Ka31097
	for <tismer@tismer.com>; Wed, 12 Jun 2002 13:02:23 -0500
Received: (qmail 58190 invoked from network); 12 Jun 2002 18:02:13 -0000
Received: from hermes.ironport.com (HELO hermes.Godspeednetworks.com)
	(10.1.1.5)
	by ns1-13.ironport.com with SMTP; 12 Jun 2002 18:02:13 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
content-class: urn:content-classes:message
Subject: RE: [Stackless] Asyncronous IO (Was: Re: question about stackless)
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Date: Wed, 12 Jun 2002 11:02:13 -0700
Message-ID: <A526A344E7CBD844B1C09524F5BC3724195384@hermes.Godspeednetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Stackless] Asyncronous IO (Was: Re: question about stackless)
Thread-Index: AcIR/BUUs+8aYwf8SSOhmxgkx8cShwAPWubA
From: "Sam M. Rushing" <srushing@ironport.com>
To: <psheer@icon.co.za>, "Ctismer (forward)" <tismer@tismer.com>
Cc: "Russ Cox" <rsc@plan9.bell-labs.com>, <stackless@tismer.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by trixie.triqs.com id
	g5CI2Ka31097

> -----Original Message-----
> From: Paul Sheer [mailto:psheer@icon.co.za]
> > This is why I first thought of kqueue: With kqueue, you
> > can also wait for file reads to become ready.
> > I have to learn more about the choices and find a good
> > abstraction.
> > Recommended material, which I'm working through now:
> > http://www.kegel.com/c10k.html
> > 
> 
> c10k.html: this is just the web page i have been looking for :-)
> 
> ok, but does this mean you are going to limit support to
> FreeBSD? I assume you are going to emulate a kqueue with
> select() for other systems?

The idea isn't to hard-code support for a particular event system,
but to have a feature set in the scheduler that can take advantage
of the features provided by the best of the current crop of event
API's.

It'd be nice if we had a system where someone could cleanly drop in
support
for (say) Win32's various API's (like completion ports) and not have to
re-architect the scheduler to take advantage of some extra feature or
performance tweak provided.

For example, the kqueue() interfaces have a nice way of returning
information along with a triggered event - e.g. if you're waiting on a
listening socket, a 'ready for read' event will tell you how many
sockets
are in the queue - this is something that select() and poll cannot do.

-Sam

]