[Libwebsockets] recent changes breaking DomTerm

Andy Green andy at warmcat.com
Tue Jan 23 08:43:12 CET 2018



On 23/01/18 14:32, Per Bothner wrote:
> Rather belatedly I updated my libwebsockets check-out (motivated
> by trying to build DomTerm on Ubuntu) and I ran into a number of problems,
> which I don't have a full handle on.
> 
> (1) This change:
>      commit 5b74d7108b5cfcc3a6ee3dcad521e0f0c3a18d0c
>      Date:   Tue Nov 14 11:25:54 2017 +0800
> changed the LWS_WITH_ZIP_FOPS default.  This took me a while to
> figure out, party because it was confounded by other issues (see below).
> 
> Some questions (I apologize if I missed some discussion on the list):

Unfortunately "discussing things on the list", unless someone else 
started the conversation just tends to be me announcing things into silence.

> (a) Why did the default change?  Of course "to reduce library size"
> is a perfectly reasonable answer, but I want to understand if there are 
> other reasons.

It's to reduce the footprint of the default library for code coverage 
purposes.  And while it's valuable for those that do, most users don't 
use it, so it should be off by default.

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

> (c) Is there a cpp conditional I can check to see if LWS_WITH_ZIP_FOPS 
> are enabled?
> I don't *have* to have LWS_WITH_ZIP_FOPS enabled, but I need to be able to
> check if it is, preferable in DomTerm's configure script.

The build generates lws_config.h which is included by libwebsockets.h. 
So all the exported symbols from CMake are available to anything that 
included libwebsockets.h.

> (2) Once I re-built libwebsockets with -DLWS_WITH_ZIP_FOPS=1 things
> work for the 5b74d7108b5cfcc3a6ee3dcad521e0f0c3a18d0c, but things break
> again two commits later:
> 
>      commit df46d8827cc3c1ffd60ea5524b1074c014cd304b
>      Date:   Thu Nov 16 11:26:00 2017 +0800
> 
> I haven't tried to track down how this caused DomTerm to break.

Hm... it's a patch refactoring private stuff inside struct lws.

It breaks build or what?

> (3) DomTerm doesn't require LWS_WITH_ZIP_FOPS to be enabled.  Instead,
> if you configure it --enable-compiled-in-resources then it serves the
> needed JavaScript+CSS  directly from initialized static byte arrays.
> This works fine [*] until we get to:
> 
>      commit 1da0197798c3c19e5b60dd0e47b1724f08ce56de
>      Date:   Thu Dec 7 07:20:47 2017 +0800
> 
> which breaks the --enable-compiled-in-resources (non-zip-fops) version
> as well.   So now I'm screwed.

This patch adds logical checking for any possibility of back-to-back 
writes, with no return to the event loop inbetween, instead of just 
waiting for them to occur where the first one was a partial.  So this 
may be showing you problems related to that in your user code.

-Andy

> I haven't studied the Dec 7 commit to see how it breaks DomTerm, as it
> a another fairly complicated change.  (I wanted to summarize my
> results-so-far before going to bed.)
> 
> [*] A disadvantage of --emable-compiled-in-resources if we also want to
> provide a "pure-Java" version of DomTerm, since that needs to get the
> JavaScript+CSS from a jar file.  Being able to use the same .jar file for
> both the Java version and the C (libwebsockets) server is elegant and
> saves space, but is not essential.



More information about the Libwebsockets mailing list