Mail Archives: cygwin-developers/2002/07/29/13:20:39
In May this year, Pierre posted a message summarizing a set of
discussions about TCP/IP problem with cygwin
(http://cygwin.com/ml/cygwin/2002-05/msg00247.html). Since then,
there seems to have been no further discussion of the issues or of
the solutions he suggested there.
I've just got interested in cygwin socket support since cygserver
uses UNIX domain sockets for the client/server communication on
win9x/ME platforms. I've not run into all the problems he lists
there, but I've run into some of them, and more unfortunately.
The issues I've come across are:
*) There's a race condition in cygwin's UNIX domain socket
emulation. I've posted a patch and some discussion of this in
http://cygwin.com/ml/cygwin-patches/2002-q3/msg00184.html (plus
followups --- and I've just realised that I attached the patch as
binary data --- I'll try even harder next time).
*) The non-blocking status of a socket is not inherited when a
socket is duplicated (either via dup(2) or fork(2)). This is on
my list to look at.
*) On win98 (and possibly other non-NT systems) sockets don't seem
to be released properly so with a long-running server you get
WSAENOBUFS errors (sooner or later) and no clients can attach
until the server is restarted. This is what I'm trying to
understand right now (w/ no success as yet) --- an "equivalent"
server using winsock2 directly doesn't suffer from this problem.
*) There are a couple of reported bugs I've come across in the
MSDN archives that need to be worked around but aren't currently
(AFAICT). For example, see "BUG: Closesocket() on a Duplicated
Socket Fails to Clean Up"
(http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q198663&)
and "INFO: WSA_FLAG_OVERLAPPED Is Needed for Non-Blocking Sockets"
(http://support.microsoft.com/default.aspx?scid=kb;[LN];Q179942).
One idea I've had is to extend the semphore work I put into the
UNIX domain socket patch to allow the DLL to detect the last close
of a socket if it's been duplicated by whatever means. This would
allow the DLL to close the socket "properly" (e.g. non-blocking +
shutdown(2) + linger as appropriate). It would also mean that
nothing special would need to be done in fhandler_socket::close
for most cases. It might also be possible to work around the bug
mentioned above (Q198663) by this method. It would require a
semaphore to be created for every socket that gets duplicated (the
semaphore that my patch uses for UNIX domain sockets could be
re-used for this purpose too so they would still only need the one
semaphore).
Comments warmly welcomed, particularly if they are of the form:
"here's a way to get around all these problems w/o having to do
any work" :-)
// Conrad
- Raw text -