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

[Conrad T. Pino]

> From: Derek Price
> Sent: Tuesday, September 27, 2005 06:32
> 
> Two thoughts.  First, assuming that you have a single fd namespace,
> which I am not sure of, then you could wrap only the open() functions
> used by CVS to store an index into a private array or hash which
> retained whatever information about the new file descriptor that you wished.

We can skip this given what is said below.

> Secondly, I think all this determining the difference between sockets
> and files is all moot - Windows handling is already so different for
> sockets and files that we have to use recv() with sockets instead of
> read(), which is why we were dealing with all that socket-client stuff
> last week. All CVS sockets on Windows are wrapped in socket_buffers
> rather than fd_buffers.  Anyhow, the select() function in
> fd_buffer_input() will only ever need to tell the difference between a
> pipe and a file descriptor on Windows, for that reason.

Eureka!!!  You're brillaint!!!!!!

A generalized "select" replacement to handle mixing socket and CRT handles
has the overlapped number space problem.

A solution for files and pipes doesn't have the overlapped number space
problem because the functions that creates pipes in "windows-NT/run.c"
wraps the Win32 API HANDLEs with "_open_osfhandle" which puts them in the
CRT number space.

Distinguishing between disks and pipes with sockets out of the picture is
trivial with the "GetFileType" Win32 API function:
http://msdn.microsoft.com/library/en-us/fileio/fs/getfiletype.asp

> Regards,

Ditto,

> Derek

Conrad