cygwin bugs

Thu Jul 3 11:59:00 GMT 1997

Hi,
 Here are a number of bugs I have come cross:
- Signals cannot interrupt certain operations.
 Signals are not able to interrupt certain operations like
 a blocked read on a socket. This causes some processes to
 be unkillable (amoung other things). Killing the process from 
 the task manager stops the process but the cygwin state is not
 cleaned up until the last cygwin process exits.
- read() behaves differently than in unix.
 When doing a large read() on a socket, cygwin will block until 
 the read completes. Unix will block until there is data and
 then return whatever data is available (ie. the amount returned
 by FIONREAD). While I believe cygwin's behavior is allowed by
 the definition of read(), it is unexpected behavior to unix
 programmers.
- select() behaves different than unix.
 When doing a nonblocking connect(), unix will allow the
 socket to select for writing when the fate of the connection
 is known (either success or failure). Winsock on the other
 hand will allow the socket to select for writing when the connection 
 succeeds and select for exceptions when the connection fails.
 Cygwin's select() has the same behaviore as winsock's select.
 The solution would be to fold the exception bits into the write
 bits, but only when a socket is connecting. When a socket has
 already connected then selecting for exceptions means that
 urgent data may be read, and the exception bits shouldn't
 be folded into the write bits.
- nonblocking sockets dont connect() when you tell them to.
 When establishing a connection on a non blocking socket,
 the connection is not established until the select()
 operation. From the programmers point of view the process
 appears normal, but if you observe the packets on the wire, they
 are not sent until the select() after the initial connect().
 This is a bug in winsock and may not be worth working
 around.
- Getpeername() sometimes fails when it shouldnt.
 When establishing a connection on a non blocking socket,
 getpeername may fail immediately after a connection
 has been made. If the getpeername() function is called
 immediately after the socket has connected (and selected
 for writing), getpeername will sometimes fail with an
 error indicating that the socket is not connected.
 If a sleep is injected before getpeername is called, getpeername
 This is a bug in the winsock getpeername function. Perhaps
 there is an alternate way of getting the peer that is not
 flawed (getsockopt?) or some operation that can be performed
 before getpeername that will insure that getpeername operates
 correctly.
I am also trying to build a copy of cygwin from the sources.
I noticed in many places the "#include_next" directives
were failing when xgcc was being used to build programs.
There were also other errors that I ran across. Has anyone
put together a list of instructions to build cygwin and
work around these errors?
 Tim N.
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".