On Wed, 17 Jun 2009, Mohun Biswas wrote:

> 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.

Yes I think that's just a mistake and the documentation could be fixed to
mention this.

> 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.

Yeah, the parameter is rather useless for that function. I agree we could
support NULL there just fine.

> 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.

While there's nothing that says you MUST use it, I would claim it is good to
use. But sure, I can agree to allowing a NULL there if you really do want to
ignore it and figure it out otherwise.

-- 
  / daniel.haxx.se