[Libwebsockets] recent changes breaking DomTerm

Andy Green andy at warmcat.com
Sat Jan 27 01:23:31 CET 2018



On 27/01/18 02:52, Per Bothner wrote:
> DomTerm trunk now works with libwebsockets trunk.  Yeah! I fixed
> any regressions that I noticed so far, but I will continue testing.
> Thanks for you help.

Great.  The back-to-back stuff (now it covers RAW properly...) is lws 
being more proactive in enforcing restrictions that already existed, but 
that you could usually get away with.  So although it's a bit painful, 
the result will be solid against different kinds of network link and 
network conditions.

>>> (b) I'm concerned that if the default changed, people who distribute
>>> compiled libwebsockets might stick with the default, which might 
>>> complicate
>>> building DomTerm using a system libwebsockets package.
>>
>> Yeah.  It's a reasonable concern.
>>
>> Lwsws should also be on by default in packaging.  There are lots of 
>> other features like ACME support now in master that should be on.
> 
> Would it make sense to have a cmake option that that turns on
> LWS_WITH_ZIP_FOPS and other options that are recommended/suggested for
> library packagers?
> 
> Something like LWS_PACKAGE_DEFAULTS or LWS_PACKAGING_RECOMMENDED?
> This could be mentioned in READMEs/README.build.md

Yes it's a great idea, thanks.  I pushed a patch adding an 
LWS_WITH_DISTRO_RECOMMENDED=1, note in READMEs/README.build.md and 
updated the example rpm specfile to use it.

> One might argue that LWS_PACKAGE_DEFAULTS=1 *might* be a reasonable 
> default,
> assuming most people are running machines with plenty of memory, and the
> people running on more constrained systems will probably have to customize
> their build for their specific needs anyway.

Well, people won't use features that were default-enabled but they don't 
know about them.

And although for PC case it's reasonable, many people gravitated to lws 
because they have weak / restricted platforms, or integrate it in 
something else; the weakest platform we support atm is ESP32.

So what I ended up with is wanting the test apps to work out the box, 
anything not needed for that is optional.  CMakeLists.txt is reformatted 
a few months ago with the options in sections so it's easy to see what's 
available.

> Are people running "small" systems generally using static libraries?

If it's "small" but Linux, usually they have multiple executables in 
their rootfs and are using dynamic libs.  Static only makes sense if you 
basically have one app in the system; if you have many apps up that 
depend on eg, libssl, with dynamic link there is only one copy usually 
of libssl in physical memory no matter how many apps are running that 
use it.  With static linking, n apps that have libssl.a have the 
corresponding footprint in physical memory for each instance's paged-in 
parts separately, since they no longer resolve to a common lib, it's 
worse if n > 1.

Of course there can be overriding considerations, static link is useful 
is you want the thing to unconditionally work even if the rest of the 
rootfs is missing etc.

> If so, that provides a way for them to "automatically" only link in
> what they need - assuming the library avoids static cross-module 
> dependencies.

Yes the ESP32 stuff is using function-level linking to get that behaviour.

However a lot of the cmake options have implications, eg allowing for 
extensions changes the sizes of various structs and creates additional 
calls in various places just in case there's an active extension. 
Function-level linking doesn't remove this overhead.

Enabling everything brings in additional libraries... on the basis 
people may be unaware of the feature if on by default, and get no 
benefit, this is bloat effectively.  For permessage-deflate extension, 
that also has implications for runtime CPU and memory on both client and 
server side, but if it exists browsers will negotiate it; having it on 
by default unknown by the developer may be exactly what he doesn't want. 
  At least if he goes in and enables it, he knows it exists and he chose 
to have it on.

For distro use, enabling most things makes sense because they can't 
predict what the user may want from it and then covering all the bases 
is the way to go... and it's pretty cheap on a PC type system.  If they 
wanted to optimize their system completely there are many ways using a 
generic distro goes against that, not least glibc itself.

-Andy



More information about the Libwebsockets mailing list