-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[discussion] Enable GLIB support on Debian/Ubuntu by default. #1980
Comments
Oh... I know they use lws but I didn't know it was glib-based, it's a good point.
I think it's probably not the sticking point, the problem for distros is how many lib packages it pulls in and then they pull in lib packages and suddenly installing anything pulls in most of the distro even if you don't want anything except the default. This is because the packaging tools, great as they are at what they do, don't have a good way to deal with build-time configuration, except gentoo but it's not packaging in the same way. Since lws is also targeted at firmware type builds eg in RTOS, the build-time configuration granularity makes a lot of sense and is definitely needed... for it. glib is just one config issue for me, https://libwebsockets.org/git/libwebsockets/tree/CMakeLists-implied-options.txt?h=_temp#n76-113 the default config and what you want from a distro package are a bit different, that build-time flag is trying to encapsulate that difference. |
I think GLib is always there on Ubuntu/Debian so it's not a reason to care about... What about RTOS and other firmware like targets - it's good point, and that's why I'm talking only about Debian/Ubuntu... |
If so, it makes sense for glib. |
While Janus uses GLib, we are not strictly speaking event based. It's not correct to say, for instance, that if libwebsockets used GLib we wouldn't need the thread: we'd still do, to handle the GLib event loop instead of the internal lws loop, since there's no main loop we can hook up to, e.g., in the core. Each plugin in Janus is responsible for its own threading and event loops (if any), so it really doesn't matter how either is implemented. I'm personally very happy with how libwebsockets works and performs! GLib or not wouldn't make a difference to Janus, so please don't use that as a bullet point in the "pros" list 🙂 |
The question is if |
If there's already a loop, it's clearly much better to have everything use that, avoid threads / locking etc, pretty much whatever it is. If there isn't, default lws service loop is based on poll() on unix, it's fine, but its timeout that drives the lws_sul scheduler is actually ms-resolution. Depending on the backend, event libs may provide better time resolution; lws apis are all us-resolution. Otherwise they should all do the same job one way or the other. It's a bit of a fine choice choosing the event lib since (outside of lws wrapping it) the apis are incompatible and often the choice is made for you by something else already having made its choice. Probably this difference about scheduler resolution isn't going to be the driving consideration. |
Yep, and in Debian/Ubuntu world that decision already was made to choose glib. When I first look to libwebsockets it was big surprise to me it doesn't support Glib event loop. And I had to invent my own GSource for libwebsockets, since I had to work with GStreamer in the same application and it already Glib based... |
But finally (very big thanks to @lws-team) native glib support was added. |
I think the answer to this (and The event lib stuff is already managed by an ops struct normalizing all the interfaces between the different backends, and there's already working libdl code for protocol plugins. The main problem is the pt and the wsi contain things that are composed from event lib types, if that was allocated at the end of the pt or wsi at runtime after consulting the selected event lib plugin to learn the opaque size at pt or wsi creation time, it could be solved. And the plugins could be built after lws in isolation, so the current gnarly conflicts between libevent and libev headers can also be overcome since they would never meet. But I am not sure what timescale that will happen at. |
I have implemented this on master, there's a readme about the changes here https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.event-libs.md The individual event lib plugins go into the same dir as the main libwebsockets.so / .a and one is selected at runtime according to which event loop is wanted. The eventlib-foreign example has been refactored to also isolate the build of the event-lib native pieces, instead of try to bring the event lib headers into one place along with the removal of the event-lib exports from lws build (except libuv if you want it bound to the main lib for lwsws or windows) this means you can indeed build all 4 event libs in one hit into the isolated plugins without any more conflict. Please give it a try. |
Event lib support as it has been isn't scaling well, at the low level libevent and libev headers have a namespace conflict so they can't both be built into the same image, and at the distro level, binding all the event libs to libwebsockets.so makes a bloaty situation for packaging, lws will drag in all the event libs every time. This patch implements the plan discussed here #1980 and refactors the event lib support so they are built into isolated plugins and bound at runtime according to what the application says it wants to use. The event lib plugins can be packaged individually so that only the needed sets of support are installed (perhaps none of them if the user code is OK with the default poll() loop). And dependent user code can mark the specific event loop plugin package as required so pieces are added as needed. The eventlib-foreign example is also refactored to build the selected lib support isolated. A readme is added detailing the changes and how to use them. https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.event-libs.md
Event lib support as it has been isn't scaling well, at the low level libevent and libev headers have a namespace conflict so they can't both be built into the same image, and at the distro level, binding all the event libs to libwebsockets.so makes a bloaty situation for packaging, lws will drag in all the event libs every time. This patch implements the plan discussed here #1980 and refactors the event lib support so they are built into isolated plugins and bound at runtime according to what the application says it wants to use. The event lib plugins can be packaged individually so that only the needed sets of support are installed (perhaps none of them if the user code is OK with the default poll() loop). And dependent user code can mark the specific event loop plugin package as required so pieces are added as needed. The eventlib-foreign example is also refactored to build the selected lib support isolated. A readme is added detailing the changes and how to use them. https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.event-libs.md
This has been released as described on v4.1, so closing this. |
@gcsideal @lws-team I've decided create separate issue to avoid offtopic in #1979
Some thoughts about %subj%:
GLib
support inlibwebsockets
was introduced only 5 month ago. So many of potential library users can just do not know about it. Or at least had no chance to update their code yet;GLib
is more widely used in world on Ubuntu/Debian (and clones) thanlibuv
andlibev
and it will be very strange if 2 last will be supported by default (and them already enabled in latest Ubuntu versions) butGLib
will not;GLib
support implementation is less than five hundred code lines (including comments), so don't think it will increase result library size significantly;Glib
support will be disabled by default, it's very unlikely applications will use it ever, just because it will require rebuildlibwebsockets
from sources on every target machine, which is very inconvenient;GLib
support for years inlibwebsockets
. For example Janus Server is based onGLib
event loop, but had to add separate thread to managelibwebsockets
related stuff (it useslws_service
based loop);P.S.: I hope @lminiero will vote for enable
GLib
support too.P.S.S.: I don't care too much about %sub%, since I used to pack my applications as snap packages, so it's not a big deal to build
libwebsockets
from sources there.The text was updated successfully, but these errors were encountered: