This is the mail archive of the cygwin-patches mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Open sockets non-overlapped?

On 6/13/06, Corinna Vinschen wrote:
On Jun 13 11:47, Lev Bishop wrote:

> It seems it's hanging in fhandler_socket::close(), when the child
> process closes the listening socket.

Hanging? Or looping endlessly with WSAEWOULDBLOCK?

Actually, it's very strange. It gets stuck on the setsockopt() in fhandler_socket::close(). There's a race with the parent (which is why it didn't happen under strace or sshd -d), but if the parent gets round to doing its select() before the child does the close(), then the setsockopt() does not return until after the select() returns. I attach a short testcase which reliably demonstrates the problem for me. It doesn't use privilege separation or non-blocking sockets, so that is not the problem. I haven't investigated whether it's something to do with the way the socket is duplicated into the child (WSADuplicateSocket() versus DuplicateHandle(), and such).

Just to spell it out: the problem shown in my testcase, is only
exibited with overlapped sockets. Non-overlapped don't have any
problem. Which is strange to me, since MSDN makes no mention of
situations where setsockopt() can block.

 Any change when not
setting the linger option, maybe?

Well, yes, because then there's no setsockopt() call to block on, but it doesn't really solve the problem, because now if the user code calls setsockopt() it will still unexpectedly block.

I think that's as far as I'm going to go with persuing this issue. If
I need native programs to use sockets, then I'll pipe them through


Attachment: fork.c
Description: Text document

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]