[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CVS Feature On Windows Very Broken - Windows "select" Semantics
From: |
Conrad T. Pino |
Subject: |
RE: CVS Feature On Windows Very Broken - Windows "select" Semantics |
Date: |
Tue, 27 Sep 2005 12:11:43 -0700 |
> 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