Skip to content
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

Closed
RSATom opened this issue Jul 20, 2020 · 11 comments
Closed

[discussion] Enable GLIB support on Debian/Ubuntu by default. #1980

RSATom opened this issue Jul 20, 2020 · 11 comments

Comments

@RSATom
Copy link
Contributor

RSATom commented Jul 20, 2020

@gcsideal @lws-team I've decided create separate issue to avoid offtopic in #1979

Some thoughts about %subj%:

  1. GLib support in libwebsockets 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;
  2. GLib is more widely used in world on Ubuntu/Debian (and clones) than libuv and libev and it will be very strange if 2 last will be supported by default (and them already enabled in latest Ubuntu versions) but GLib will not;
  3. GLib support implementation is less than five hundred code lines (including comments), so don't think it will increase result library size significantly;
  4. If Glib support will be disabled by default, it's very unlikely applications will use it ever, just because it will require rebuild libwebsockets from sources on every target machine, which is very inconvenient;
  5. Some applications had to use some workarounds of missing GLib support for years in libwebsockets. For example Janus Server is based on GLib event loop, but had to add separate thread to manage libwebsockets related stuff (it uses lws_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.

@lws-team
Copy link
Member

Janus Server is based on GLib event loop

Oh... I know they use lws but I didn't know it was glib-based, it's a good point.

don't think it will increase result library size significantly

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, LWS_WITH_DISTRO_RECOMMENDED is the stuff that ultimately seems should be in a distro lib for best consumption for all the common options, and development with packaged binary lib, plus or minus the libevent vs libev conflict. I annotated that to make it clearer most of the options are selfcontained and list any related libs where it isn't.

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.

@RSATom
Copy link
Contributor Author

RSATom commented Jul 20, 2020

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...

@lws-team
Copy link
Member

I think GLib is always there on Ubuntu/Debian so it's not a reason to care about

If so, it makes sense for glib.

@lminiero
Copy link

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 🙂

@RSATom
Copy link
Contributor Author

RSATom commented Jul 20, 2020

The question is if lws_service will be less (or more) efficient than GSource based events handling...

@lws-team
Copy link
Member

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.

@RSATom
Copy link
Contributor Author

RSATom commented Jul 20, 2020

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...

@RSATom
Copy link
Contributor Author

RSATom commented Jul 20, 2020

But finally (very big thanks to @lws-team) native glib support was added.

@lws-team
Copy link
Member

I think the answer to this (and LWS_WITH_DISTRO_RECOMMENDED) ultimately is plugin type event lib backends, it will result in a main package as usual, and then like lws-eventlib-glib package containing the glib event loop plugin that can be brought in by anything that wants that. Packages just requiring core lws bits and don't care about the event loop just express a dependency only on libwebsockets package and not the plugin packages. And lws can go and dynamically load one of the available plugins at context creation time according to which event loop type set in info.options.

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.

@lws-team
Copy link
Member

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

https://libwebsockets.org/git/libwebsockets/tree/minimal-examples/http-server/minimal-http-server-eventlib-foreign

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.

lws-team added a commit that referenced this issue Aug 30, 2020
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
lws-team added a commit that referenced this issue Sep 1, 2020
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
@lws-team
Copy link
Member

lws-team commented Sep 6, 2020

This has been released as described on v4.1, so closing this.

@lws-team lws-team closed this as completed Sep 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants