bug-cvs
[Top][All Lists]
Advanced

[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: Wed, 28 Sep 2005 00:42:10 -0700

> From: Conrad T. Pino
> Sent: Tuesday, September 27, 2005 12:12
> 
> > 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

I may have spoken to soon.  I found some good pieces but the devil is always
in the details.
==============================
I believe we've agreed these "woe32_fd_select" behaviors are acceptable:

1. Disk files are always ready for reading.

2. Disk files are always ready for writing.
==============================
To that can we add these behaviors and constraints?

3. Pipe files are always ready for writing.

4. Disk files will NOT be queried for exceptions.

5. Pipe files will NOT be queried for exceptions.

6. Console or tty files will NOT be queried for anything.
==============================
The reason for #3 is "PeekNamedPipe" can only query the read end:
http://msdn.microsoft.com/library/en-us/ipc/base/peeknamedpipe.asp
A query of the write end results in ERROR_ACCESS_DENIED.

The reason for #4 to #6 is defer work on possibly unused functions.

The "PeekNamedPipe" function doesn't support waiting of any kind
so we need to examine the case for monitoring multiple pipes for
reading.  Does this in fact occur?

Conrad





reply via email to

[Prev in Thread] Current Thread [Next in Thread]