Date: Fri, 21 Mar 2008 17:06:36 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #5925] Windows socket(...) returns SOCKET, not file handle
Message-ID: <20080321220636.GB16998@Sun.COM>
Mail-Followup-To: rt@krbdev.mit.edu
References: <rt-5925-26227.15.1985425554629@krbdev.mit.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <rt-5925-26227.15.1985425554629@krbdev.mit.edu>
User-Agent: Mutt/1.5.7i
RT-Send-Cc: 
Content-Length: 1498

On Fri, Mar 21, 2008 at 05:37:13PM -0400, Jeffrey Altman via RT wrote:
> Kevin Koch via RT wrote:
> > sendto_kdc.c start_connection(...) calls socket(...).  
> > 
> > The returned SOCKET is treated as a file handle.
> > 
> > On Windows, the SOCKET is greater than FD_SETSIZE, so close is called.  
> > The SOCKET is also greater than the number of file handles, so close 
> > asserts.
> 
> (1) close() is a C Runtime Library function that only works on C RTL 
> file descriptors.   closesocket() must be used for SOCKET returned by 
> socket().
> 
> (2) FD_SETSIZE in winsock has no relation to the value of SOCKET 
> handles.   FD_SETSIZE is the number of sockets that can be stored in an 
> fd_set.  It is not a maximum bound on the value of the handle.
> 
> Arrays of FD_SETSIZE are not safe to use on Windows.  Alternative data 
> structures must be designed that will work on all platforms including 
> UNIX/Linux systems whose "ulimit -n" values are raised above FD_SETSIZE.

Agreed.

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).

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.

Nico
--