libev and libevent

Harald Geyer harald at
Mon Feb 19 14:01:49 CET 2018

Andy Green writes:
> For downstream maintainers like me whose users wish to be able to use 
> both, and where distro consumers should be able to tick all the boxes 
> and choose at runtime, are there any ideas what can be done to improve 
> the situation?

It might be a good idea to support selecting between libraries at compile
time; I'm not going to comment on that.

But what you are proposing here made me speechless for a while. What
is "choose at runtime" even supposed to mean? Do you link to all of them
and then control into which one the code actually calls? Do you dl_open()
the one you want to use when the application starts?

I can't see how this can possibly work. Or rather: Any solution I can
think of requires a lot of abstraction code probably causing enough
overhead to make the exercise pointless.

But really: What's the point of choosing the event loop implementation
at run time? If there is something for the distribution user to choose
from, then clearly multiple options are available in the distribution.
So why not just pick one at compile time?

If you really insist on making the event loop implementation selectable
(probeable?) at runtime, then I think the only viable approach is to
move all your event loop facing code into a separate module and compile
this module multiple times - once per event loop supported. Then the
right instance of the module can be dynamically linked at run time by
either having the right symlinks in place or dl_open().


If you want to support my work:
or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN
or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

More information about the libev mailing list