Message-ID: <47E44385.8070201@mit.edu>
Date: Fri, 21 Mar 2008 17:23:49 -0600
From: Jeffrey Altman <jaltman@mit.edu>
User-Agent: Thunderbird 2.0.0.12 (Windows/20080213)
MIME-Version: 1.0
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5925] Windows socket(...) returns SOCKET,	not file handle
References: <rt-5925-26228.9.30854029082163@krbdev.mit.edu>
In-Reply-To: <rt-5925-26228.9.30854029082163@krbdev.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: jaltman@mit.edu
RT-Send-Cc: 
Content-Length: 1189

Nicolas Williams via RT wrote:

> You might want to consider using libevent, which has support for "Linux,
> *BSD, Mac OS X, Solaris and Windows" and which is distributed with a
> 3-clause BSD license (but without the advertising clause).

It has a documentation requirement for the party that distributes
the libevent library or binaries that include the library.  For KFW, I 
believe the copyright and inclusion of libevent will have to be 
documented.  The license can be found at:

   http://www.monkey.org/~provos/libevent/LICENSE

> This should result in more portable code and should allow you to let
> someone else worry about the low-level details of I/O polling and async
> I/O on each OS.  With any luck you might even be able to reduce the
> amount of source code related to I/O polling and async I/O in MIT krb5
> significantly.

Looking over the examples this looks like a very easy fix to the I/O
issues related to the use of UNIX fds larger than FD_SETSIZE.  Using 
libevent would be a definite win.

However, in locations where the socket fd is being used as an index
into an array of objects switching from select() to libevent will
not be the solution.

Jeffrey Altman