cURL / Mailing Lists / curl-library / Single Mail


Re: fd_set beyond 1024 problem

From: Daniel Stenberg <>
Date: Sat, 2 Jun 2007 11:52:17 +0200 (CEST)

On Sat, 2 Jun 2007, Aleksandar Lazic wrote:

>>> It isn't clear to me what the portable way of raising this limit is for
>>> fd_set, but I feel a strong urge to fix this issue.
>> So I suggest defining your own type and macros, if using `poll'.
> As some of the high performance server out ther do.
> I think you will find some ideas in haproxy, nginx, thttpd, lighttpd,...

Thanks for the suggestions and help, but the fix for us was actually "easier"
than so: the last use of select() in libcurl was still present due to c-ares
returning information and providing an API that only fit select(). I modified
c-ares to allow a more "direct" approach that operates directly on the given
socket/file descriptor, and then I could just rip out the use of select() from

That's why we now require c-ares 1.4.0 for libcurl if you want to do asynch
name resolves. I hope to release that soon, and I intend to do it before I can
release libcurl 7.16.3. There's only a few remaining patches to go in and a
little more testing to be done. Unfortunately, I'm the maintainer of c-ares as
well so that work ends up on me too...

libcurl now uses poll() all over internally, and only those systems that don't
have a native poll() will use select() as then we emulate poll() by using
select(). In today's world, there won't be many systems that don't have poll.
I can mostly think of Windows before Vista and Mac OS X, and possibly we can
work things out on the Mac side one day (and they might even fix their poll
one day).

  Commercial curl and libcurl Technical Support:
Received on 2007-06-02