This is the mail archive of the
mailing list for the Cygwin project.
Re: Open sockets non-overlapped?
On Jun 15 12:07, Lev Bishop wrote:
> 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.
Erm... I tested your testcase and I can reproduce the hang only when
using NON-overlapped sockets created with WSASocket(..., 0).
It works fine with overlapped sockets created with select or
WSASocket(..., WSA_FLAG_OVERLAPPED). I assume the above is just a
> 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
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com