Open sockets non-overlapped?

[Corinna Vinschen]

On Jun 12 21:43, Lev Bishop wrote:
> It doesn't make it any less useful to native processes _as a socket
> handle_ but it does make a difference when the native processes use it
> _as a file handle_. As you know, the semantics of WriteFile() et al
> change completely depending on whether they get an overlapped handle
> or not (eg the LPOVERLAPPED parameter either _must_ be null or _must
> not_ be null [...]

Uh, yes, right.  I can see the potential benefit.  Is the behaviour
of ReadFile/WriteFile with overlapping sockets the same?  Did you try
to write a native testcase (not cygwin) to test this and find out
what happens when no Cygwin is involved at all?  This might give us
some interesting clews.

> Hmph. It works for me. Must be some difference in our configurations,
> windows versions, etc. I note that msdn warns that using socket
> handles as file handles is an optional feature and not all providers
> support it. I guess the provider must be both a Winsock provider and
> also a file-system driver in order to make this work. Maybe you have
> some LSPs on your machine or something?

XP SP2 w/ official updates, plus SFU NFS and a bluetooth stack.

Standard AF_INET sockets should usually work, though.  There's nothing
but standard file/socket types involved in this example.  After all,
I'm running `cmd /c dir' on my NTFS home dir and the AF_INET socket
provider is Microsoft's own.  Maybe I'm naive, but I would assume that
this problem would only happen with 3PPs.


Corinna

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