On Wed, 4 Jan 2012, Christian Hägele wrote:

>> Here's my suggested patch that simply removes the use of the dummy socket
>> in the win32 version of the threaded resolver.
>
> I tested your change on my application. My application runs fine. But I
> couldn't figure out yet how to run the unit-tests on windows (it is a pain
> to get it running on windows), but I assume some of them will fail with just
> looking at the code.

I've long since given up the quest of running tests on "pure" windows. I think
using cygwin for that is the only sensible approach - I mean that won't
involve a lot of work and code changes.

> If you do a full-text search for curl_multi_fdset you will see that that
> nearly nowhere is checked if the maxfd return value is -1. Actually select
> is used in this case as a plain sleep. But this WILL fail on windows,
> because select returns an error if no sockets are provided.

Yes, but as I explained before that's a buggy behavior and such code will
_already_ fail when the non-win32 threaded resolver is used.

> These are the cases which I found which could be problematic:

...

> It looks like these example use a copy&pasted code-snippet with
> curl_multi_fdset.

They all (?) feature the very big comment below the curl_multi_fdset() that
explains the situation and that an application MUST check maxfd for -1 to work
properly.

But you're right. We should insert proper checks into these places so that
less people copy and use the incomplete versions without reading the embedded
comments.

> Personally I am fine with that change and as it was documented that way all
> the time, the users should fix their programs.

This is what I want to lean back on.

Of course I am open to people's opinions if there are others who agree or
disagree or whatever.

-- 
  / daniel.haxx.se

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-01-04