On Fri, 13 May 2011, Brett Simmers wrote:

> Using libcurl 7.21.6 (on Windows 7 x64), I can use the OPENSOCKETFUNCTION
> and SOCKOPTFUNCTION callbacks to manually open a file handle on the named
> pipe and prevent libcurl from attempting to connect it (by returning
> CURL_SOCKOPT_ALREADY_CONNECTED from the sockopt callback).

I like it that you found use of this feature, as it was just added! =)

> I'm told that file and socket handles are interchangeable on Windows as long
> as the standard read/write APIs are used.

Yes that might be true, but as I remember it they're not the same when used
with select() or similar socket-using functions.

> Unfortunately, it looks like there are still a number of other things inside
> libcurl that need the socket handle to actually be a socket instead of a
> file handle.

Yes. I think this idea has been pushed forward in the past but never actually
been made into reality. I think there's some fixing left to make this
possible.

> Has anyone ever done this before, or do you have any tips on how I could
> make this work? Are there more callbacks or options I can set to get more
> control over the sockets used by libcurl? I've been scanning the docs
> without much luck.

I wonder if we should introduce another return code for this purpose:
CURL_SOCKOPT_SOCKET_IS_FILE or so. Then we internally would not do
socket-specific action on that file descriptor.

It'd take some code edits and some testing to get working. The biggest problem
might be that select() or poll() won't work with file descriptors on Windows
(but will on *nix).

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html