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 can't choose libevent + libev in lws cmake.
Thanks for your careful consideration and flexibility, everyone!
-Andy
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
_______________________________________________
libev mailing list
[email protected]
http://lists.schmorp.de/mailman/listinfo/libev
