Re: Open sockets non-overlapped?

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

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
typo?

> 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
> socat.

ACK.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat