Brian Akins wrote:
> >This will work just fine for the vast majority of applications, especially
> >on Linux where select handles 1024 sockets by default.
>
> In my application, I frequently have several thousand open file handles
> (8k+).
>
> I've suggested this before, why not just use something like libevent
> which has already figured this out and can use epoll, /dev/poll/,
> kqueue, etc?
>
> http://www.monkey.org/~provos/libevent/

libevent is quite good, and there as several other libraries which
offer a similar interface. evlib, libasync and libasync-smp are worth
a look.

I am trying to convince Daniel to use an API which is _compatible_
with libevent and libevent's performance characteristics, but does not
depend on that library.

(You'll notice that all the high performance event-driven I/O libraries
use a similar API to libevent.)

Problems with libevent in this context are:

   - (I guess) it's not as portable as curl.

   - It's not thread safe (look at the RT I/O signal code "rtsig")
     when used in a threaded program, even if it's called from only
     one thread.

I've been writing something like libevent which solves these problems
and also improves performance, for my own use. But there is also:

   - It's not suitable when you need to wait for things that libevent
     doesn't handle, or when you have to use another kind of waiting loop
     e.g. as in a Gnome application.

The point, anyway, is that curl should not be tied to something like
libevent, but it should be easy for an application to use them together.

Maybe curl should even use libevent/other by default if they're
available at compile time. But it shouldn't tie the application to
using a specific event library because that limits applications
considerably.

-- Jamie
Received on 2005-02-10