libev and libevent

Andy Green andy at
Mon Feb 19 17:40:38 CET 2018

On February 19, 2018 10:06:04 PM GMT+08:00, Marc Lehmann <schmorp at> wrote:
>On Mon, Feb 19, 2018 at 08:10:49PM +0800, Andy Green <andy at>
>> Since libevent uses the preprocessor, it gets the final say; in other
>> since it defines EV_READ etc to a different value, building some
>> that can operate with both libevent and libev results in nothing
>working or
>> not even build completing if you include the libevent bits first.
>Most software choses the event model at compile time, where this causes
>no issue. If you want to support both at runtime, just put the libev
>in one source file and the libevent code in another, and this problem

You sound confident about that, but actually having implemented it, you have not considered that the structures composing event lib state (handles, loop objects etc) must be defined in one place with types available for all event libs simultaneously.

>> This is basically an interoperability problem between libevent and
>libev, or
>> libev and libevent, it would be great if there is something that can
>be done
>> to allow the happy coexistence merry-go-round to spin once more for
>> two libraries.
>It's not really a problem in practise, and certainly not an obstacle
>users of these libraries.

*waves hand*  hellooo!

>> for libevent, but I learned there the situation is more complex than
>> expected, with libev providing some libevent compatibility by design.
>Yes, libev offers the libevent (v1) api as well.
>> For downstream maintainers like me whose users wish to be able to use
>What you described doesn't seem to be an actual problem - can you give
>more detailed explanation, maybe with an example, of what you want to
>and can't?

I explained the scenario in my other reply.


More information about the libev mailing list