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 _______________________________________________ Bug-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/bug-cvs
