Re: libev and libevent
On 20/02/18 02:05, Harald Geyer wrote: 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. libev is only supporting some deprecated libevent version from what I understood. It's not a good thing to have dirty, conflicting namespaces just for the sake of it. Libuv seems to manage it just fine. 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 ... Sure, there are many cases where you can only have one of something. This doesn't have to be one of them as I show by [1] 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. I answered this in my original reply here [2] Did we get any further? No. Because it's not going to change no matter what I say. So I actually looked at the lws packages in debian and indeed, there one binary depends on both libev and libuv... [1]... which works fine. Because libuv and libev namespaces do not conflict and despite the "shocked into silence" here, there is no problem having them in parallel. 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. [2] 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 What actually exists also works fine, and lws extends to very small targets like ESP32 where none of this is a concern. https://github.com/warmcat/lws-esp32-factory 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 Is that so. 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. Currently n = 3 and no sign of more coming... libevent was only contributed by Samsung because they use it in Tizen or whatever. It scaled to where it needed to be just fine. 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. For n = 3, it is no problem and the overhead is not measurable. I agree though, if n grew much more, it would have to trigger a refactor of some kind on my side. Now then, this is the only library we bind to where I have to tell CMake not to use -Werror on the sources where we use it, because it's not possible to use it with gcc without getting warnings. This was reported years ago and gcc blamed by the maintainer, nothing changed. Warnings for everyone on gcc was the "solution". This is the reason I tried to discuss with libevent first, but the idea libev would contain a conflicting, deprecated, libevent was beyond my withered imagination. If there is no willingness to clean this up in libev, it looks like it cannot be fixed, so I will just leave it that you
Re: libev and libevent
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
Re: libev and libevent
On February 19, 2018 10:06:04 PM GMT+08:00, Marc Lehmann wrote: >On Mon, Feb 19, 2018 at 08:10:49PM +0800, Andy Green >wrote: >> Since libevent uses the preprocessor, it gets the final say; in other >words >> since it defines EV_READ etc to a different value, building some >software >> 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 >code >in one source file and the libevent code in another, and this problem >is >solved. 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 >these >> two libraries. > >It's not really a problem in practise, and certainly not an obstacle >for >users of these libraries. *waves hand* hellooo! >> for libevent, but I learned there the situation is more complex than >I >> 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 >both, > >What you described doesn't seem to be an actual problem - can you give >a >more detailed explanation, maybe with an example, of what you want to >do >and can't? I explained the scenario in my other reply. -Andy ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: libev and libevent
On February 19, 2018 9:01:49 PM GMT+08:00, Harald Geyer 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
Re: libev and libevent
On Mon, Feb 19, 2018 at 08:10:49PM +0800, Andy Green wrote: > Since libevent uses the preprocessor, it gets the final say; in other words > since it defines EV_READ etc to a different value, building some software > 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 code in one source file and the libevent code in another, and this problem is solved. > 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 these > two libraries. It's not really a problem in practise, and certainly not an obstacle for users of these libraries. > for libevent, but I learned there the situation is more complex than I > 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 both, What you described doesn't seem to be an actual problem - can you give a more detailed explanation, maybe with an example, of what you want to do and can't? -- The choice of a Deliantra, the free code+content MORPG -==- _GNU_ http://www.deliantra.net ==-- _ generation ---==---(_)__ __ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / schm...@schmorp.de -=/_/_//_/\_,_/ /_/\_\ ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
Re: libev and libevent
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(). HTH, Harald -- 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
libev and libevent
Hi - I maintain libwebsockets (https://libwebsockets.org / https://github.com/warmcat/libwebsockets ). Thanks to user contribution over the years it now supports libuv, libev and libevent. Libevent was the most recent addition; until then lws supports the idea of building the library with bindings to both libuv and libev, and choose which one to use at runtime. So libevent was added to the happy coexistence merry-go-round. However now I get a big headache, because both libev and libevent define EV_READ / EV_WRITE, to different things. libevent says /usr/include/event2/event.h:#define EV_READ 0x02 /usr/include/event2/event.h:#define EV_WRITE0x04 and libev says EV_READ =0x01, /* ev_io detected read will not block */ EV_WRITE=0x02, /* ev_io detected write will not block */ Since libevent uses the preprocessor, it gets the final say; in other words since it defines EV_READ etc to a different value, building some software that can operate with both libevent and libev results in nothing working or not even build completing if you include the libevent bits first. 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 these two libraries. I opened a github issue at https://github.com/libevent/libevent/issues/596 for libevent, but I learned there the situation is more complex than I expected, with libev providing some libevent compatibility by design. 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? -Andy ___ libev mailing list libev@lists.schmorp.de http://lists.schmorp.de/mailman/listinfo/libev
