A little off-topic, but you sound familiar with libevent.

I've never used either but I'm looking at gevent for a project, and I noticed that they switched to libev: http://software.schmorp.de/pkg/libev.html ... do you know what "limitations and bugs" in libevent they speak of? I poked through the mailing list for libev and couldn't find anything specific.

I've never paid much attention to libev. I've been using libevent since 2002 (it was the standard event loop at Arbor Networks, which was in Ann Arbor, where Niels Provos lived at the time). Before libevent, I used ACE_reactor to accomplish the same tasks. I prefer libevent (strongly) to ACE. I might prefer libev to libevent, but... why bother? Libevent works fine.

My guess about "limitations" of libevent is that it's primarily that libevent is anchored to global state and needs to own the event loop for the program. So, for instance, to get it working in Cocoa apps, I have to spawn off a libevent thread. And I can only have one of them.

But this isn't really a big deal for me; once I got the libevent thread working, everything was peachy for me.

In no other context do I ever, ever have any need to do anything funky with how I include libevent; 90% of programs that use libevent are designed from the outset to use libevent and don't benefit from flexibility about the event library.

I have minimal experience with libevent and much more with libev, but I do think that libev is very, very well-engineered. The author is on steroids, you can really notice it just by reading the documentation. The documentation and the code indicate that he knows what he's doing and is very serious about performance. There are also no obvious design flaws in libev that would result in limitations. Want fork? No problem, but be aware of clearly documented issues A B and C. Want threads? No problems, it even documents how, as well as potential issues. Want signals? No problem, and again potential issues are clearly documented.

Niels (of libevent) is also pretty ridiculously talented; it's also hard to dispute that libevent has had more testing.

Libevent vs. libev really seems like a Linux vs. BSD kind of debate. I'd always choose libevent over libev, but you can apparently get a performance improvement (which is probably going to be marginal compared to other simple things you can do to speed up an evented program) by going with libev. And it looks like if you're doing clientside dev, like building a new browser or file transfer client, that libev is easier to embed.

There's also picoev to look into if you're interested in seeking alternatives to libevent. I don't know a huge amount about libevent and it's a bit niche, though. The meinheld WSGI server uses it, and I got nearly double requests/second compared to gevent (libevent). Not that that means much, but it's interesting.

Something like evhttp also has the benefit that you can have more than one request "in flight". FastCGI can theoretically do this, but almost no implementation supports it - and it makes e.g. writing a simple chat server much easier (one process, one thread, tons of connections, data in memory.)

The downside to doing evhttp is that he'll have to write his own request parsing (I think he's relying on Apache/CGI to do that for him now).

But if you're going to do a C web framework (and... really? you sure about that?), that's probably how you should do it.

> The downside to doing evhttp is that he'll have to write his own request parsing...

Which, these days, isn't a huge deal. Both of these are decent:

https://github.com/ry/http-parser

https://github.com/mongrel/mongrel/blob/master/ext/http11/ht...

Request parsing is no big deal, I've already written a json parser/generator for this project (though it's in a separate project atm).

Nothing is set in stone. I do admit that a libevent based asynchronous API is tempting.