Daniel Stenberg wrote:
>> The case of curl_multi_fdset is particularly confusing because it's
>> clearly inspired by select(), expecting read/write/exception fd sets.
>> But select allows any of these to be NULL whereas curl_multi_fdset
>> doesn't.
>
> This is an example of a function where allowing NULL will only encourage
> apps to do wrong and get themself in trouble! If you're going to use
> select() on libcurl's file descriptors, you better get them all!

I now think you're right here. I guess the important point is the one
just made by Richard Atterer in a different thread, that HTTP
transactions always involve both a read and a write and thus that curl
is different from generic select() in that you can't divide fd's into
read-only and write-only. And in fact the exc_fd_set can be NULL though
though the documentation does not say so. This may be only a
documentation fix.

> Perhaps you could start with presenting what functions and arguments
> you're considering.

The first two I noticed in addition to curl_multi_fdset were
curl_multi_info_read and curl_multi_perform. In the former case there's
a common idiom:

     while ((curlmsg = curl_multi_info_read(...))) { ... }

In this case you don't need the number of remaining messages because the
return code gives you basically the same information; you keep reading
till there are no more. In fact when I look at the sample code
(docs/examples/*.c) there are 5 programs which call curl_multi_info_read
and all 5 make no use of the 'msgs_in_queue' parameter; they are all
forced to allocate and then ignore it.

Similarly with curl_multi_perform: I don't use the running_handles
result. Of course my code is brand new and not actually working yet, and
all the samples make use of it, so there's still a chance it's required
and I'm doing something wrong.

Thus the only one I'm sure right now about is curl_multi_info_read but
there may well be others. Plus the doc fix on curl_multi_perform.

MB
Received on 2009-06-18