FYI: I investigated libev for an application, had a pretty good impression overall — well thought out and functional. It had a major drawback for us, though: the main loop supports various timers, and to implement that it calls gettimeofday() twice for each call to poll(). This occurs regardless of whether you’ve registered any timers or not.

We decided that was too much overhead for our app (lots of small UDP reads). It also didn’t help that libev uses a direct gettimeofday() syscall by default, instead of glibc’s faster vdso implementation (see EV_USE_CLOCK_SYSCALL).

It’s at http://github.com/tibbe/event

We could use the libev benchmark for inspirations. It opens a number of pipes and sends a byte over each like you said.

I’m implementing a Web server
with GHC. To get over the select() limitation, I wrote a C10K server library which use the *prefork* technique. That is, N processces are preforked, and a process limits acceptable connection to M. So, N * M connections can be handled.

I would contribute the benchmark stuff since my team already
know curl-loader and jMeter well. Please tell me what you want to measure…

Keep in touch.

I’ll write a benchmark some time in the next few days. It’s not a very hard job: simply open some number of connections between a client and a server, and then send a byte over a random socket every so often.

The tricky part is in accounting where the time spent goes. We might want to use the new event logging mechanism in 6.12 and ThreadScope for that.

Why do you consider using libev over raw calls to kqueue/epoll? As an another option, there is pure Haskell Event library by Johan Tibell.