On Wed, 17 Nov 2004 09:02:10 +0100 (CET), Daniel Stenberg
<daniel-curl_at_haxx.se> wrote:
> Let me first say that I really appreciate you taking on this bug!

You're welcome. Please note that this is done as part of my
employment at Adknowledge, Inc. You can add them to the list of
companies using libcurl for internal software.

> Or possibly the only function can take two read descriptors.
> [...]
> I agree. But fixing ares (or rather c-ares) is not a problem since I am the
> maintainer of that too, and I can't see how we can fix this properly without
> doing so.

I fixed telnet.c by adding Curl_poll(). This function has the same
semantics as poll() and can be called the same way.

c-ares, hostares.c and curl_multi_fdset() remain to be fixed.

> I believe we need to provide a different function than ares_fds() that returns
> a number of file descriptors for reading/writing.

Yes.

> I didn't pay attention to the details here, but based on your description here
> it sounds like you modified how it works and thus it is bound to break some
> app out there.

After reading the code again, I'm not so sure of that. It seems that
libcurl only saves fd_sets as an optimization and thus the fd_sets and
fd_set pointers in Curl_transfer_keeper could safely be removed.
 
> Yes. We should add a function that better return the file descriptors in a
> more generic manner so that the caller can use them for whatever function it
> wants to use. poll() is just one way.

A good method would be to allocate and return a struct pollfd array.

The attached patch fixes the problem spotted by Dan Fandrich. It also
includes test 515. Test 515 is the same as 500, except that it opens
more than FD_SETSIZE file descriptors before using libcurl.

What has to be done to get this patch included? Do you want to design
the new API function(s)?

-- 
David Phillips <david_at_acz.org>
http://david.acz.org/