CVS Feature On Windows Very Broken - Windows "select" Semantics

[Conrad T. Pino]

Hi Derek,

> From: Derek Price
> Sent: Sunday, September 25, 2005 07:56
> To: Conrad T. Pino
> Cc: Bug-non-GNU CVS
> Subject: Re: Windows CVS 1.12.12.1 Latest + Patch - "version" Command Hangs
> 
> Hrm?  If there was a select() function that worked to the POSIX
> semantics I already forwarded, CVS's needs should be satisfied.

The problems of feature on Windows are worse than Frank Hemmer reported:
http://lists.gnu.org/archive/html/bug-cvs/2005-02/msg00014.html

Because Windows "select" function is so restrictive the only access
method that works on feature are socket based.  I verified :pserver:
works and I expect other socket access methods to work.

I expect all other access methods to fail.  I've confirmed :ext: and
:local: methods do in fact fail.
======================================================================
I've found all the pieces to code a replacement "select" function but
we have a problem with the combination of Microsoft's C Run Time (CRT)
low level I/O functions and the Windows socket functions.

1. The Windows "socket" function returns a Win32 API SOCKET which is
in the same number space as a Win32 API HANDLE.  Win32 API effectively
defines "typedef void * HANDLE;" and "typedef unsigned int SOCKET;".

2. The CRT "open" functions returns an "int" index into a CRT internal
"typedef struct { ... } ioinfo;" array.

Unfortunately "sizeof((int)) == sizeof((SOCKET))" so telling them
apart isn't easy.  The problem is they are seperate overlapping
number spaces.  This program illustrates it nicely:

        #include <fcntl.h>
        #include <io.h>
        #include <stdio.h>

        #define WIN32_LEAN_AND_MEAN
        #include <winsock2.h>

        static void tellme( int fd )
        {
                long fl;

                fl = _get_osfhandle( fd );

                printf( "fd: %d\tfl: %ld\n", fd, fl );
        }

        int main(int argc, char* argv[])
        {
                int fd;
                SOCKET fs;
                WSADATA WSAData;

                WSAStartup( MAKEWORD( 2, 2 ), &WSAData );

                fd = open( "ReadMe.txt", O_RDONLY | O_TEXT );
                fs = socket( AF_INET, SOCK_STREAM, 0 );

                tellme( 0 );
                tellme( 1 );
                tellme( 2 );
                tellme( fd );

                printf( "\tfs: %ld\n", fs );

                closesocket( fs );
                close( fd );

                WSACleanup( );

                return 0;
        }

The "_get_osfhandle" function is described here:
http://msdn.microsoft.com/library/en-us/vclib/html/_crt__open.2c_._wopen.asp

produces this output:

        H:\cvstest>debug\cvstest
        fd: 0   fl: 3
        fd: 1   fl: 7
        fd: 2   fl: 11
        fd: 3   fl: 944
                fs: 916

        H:\cvstest>

Notice how the file descriptor (fd) 0 has a Win32 HANDLE (fl) value 3
which overlaps with fd 3 which has fl 980.

I can describe a "select" solution more but that's pointless until we
decide how to resolve number space problem.

IMO a reliable "select" replacement requires the ability to translate
a CRT file descriptor to a Win32 API HANDLE reliably.  IMO that's not
possible with 100% certainty.
======================================================================
The possible resolutions are:

1. Try heuristic algorithms based on numeric values since CRT file
descriptors tend to cluster near 0 and Win32 API HANDLE values get
large quickly.  I don't recommend this since this idea may fail in
unpredictable ways and frequency.

2. Abstract all file descriptor functions and provide replacements
for Windows that return values in the Win32 API HANDLE number space.
A reliable "select" replacement is then possible.

3. Expand the "src/buffer.c" suite to support disks, pipes and sockets
as distinct types requiring seperate support on Windows.
======================================================================
No matter which option we choose I anticipate the solution will be in
the double digit days to single digit weeks time frame but I hope I'm
wrong.

Best regards,

Conrad