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
