On February 19, 2018 9:01:49 PM GMT+08:00, Harald Geyer <har...@ccbib.org> wrote: >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.
Lws uses cmake, where the event loop support can be individually enabled and disabled. >But what you are proposing here made me speechless for a while. What I'm not proposing lws' internal workings to you. It already does this for years in liuv / libev case and all works nice. 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. >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. 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. >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. 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, >Harald _______________________________________________ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
