Hi! Disclaimer: I'm not a libev developer. Just following this list as a regular user.
Andy Green writes: > I'm proposing libevent and libev stop defining the same symbols to > different values and conflicting, the same way libev and libuv have > clean namespaces that don't conflict. It's quite basic. Actually different projects implementing the same API is a good thing. Usually people even come up with standards just to make this happen. Of course you can't link a program to glibc and musllibc at the same timer either ... > >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? If you actually answered these questions, we might already be a step further. So I actually looked at the lws packages in debian and indeed, there one binary depends on both libev and libuv... > >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. > > The overhead is simply test a bit per event library at some key points, > accept, close, change event mask. Once the enabled lib does the accept, > the selected lib directly calls the event callback itself. The overhead > is insignificant. > > >But really: What's the point of choosing the event loop implementation > > Lws has many projects using it, and they use different event loops. > Consider a distro that wants to include even two such projects using lws > as a dynamic lib... they must package lws, and the two projects... but > how do they configure lws to do that? They can build + package lws n > times for n event loops, or choose at runtime. Yes, exactly. This is what they should do. (I'm maintaining library packages for a linux distribution myself.) Ideally there would be packages lws-common lws-ev (depending on lws-common) lws-uv (depending on lws-common) app1 (depending on lsw-ev) app2 (depending on lsw-uv) If there is not enough event loop independed code to have lws-common, then lws just needs to get compiled twice to produce both flavors ... Your approach just doesn't scale. Just think about this from the perspective of a user only installing app1. With your current approach he ends up with libev and libuv installed, but one is unnecessary. Now you add support for libevent, so he has to install that two - two unnecessary packages. In the future you might add even more event loops, pulling in even more packages. This just doesn't scale well. > >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 > > This already works for many years. What you're suggesting is not enough, > because each event lib requires some state in structs related to > connections. Hence me saying the abstraction layer to do this properly would be a nightmare. Harald > At the point those structs are declared, all the types must > have been brought in from all related libs. Hence the need for headers > for the event libs to have clean namespaces. > > >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 don't see this as a problem for libevent + libev to sort out, > then not much option but keep the two impossible to select together at > cmake, unless it can be solved at libevent. > > -Andy > > >HTH, arald -- If you want to support my work: see http://friends.ccbib.org/harald/supporting/ or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
