[Libwebsockets] output.c: lws_issue_raw handle_truncated_send instead of assert(0)

Andy Green andy at warmcat.com
Sat Apr 11 01:45:20 CEST 2015



On 11 April 2015 00:21:34 GMT+08:00, Derald Woods <woods.technical at gmail.com> wrote:
>Hello Andy,
>
>The following patch allows code, that I am working with, to survive
>browser
>refreshes while streaming larger chunks of data (~500k). SSL is enabled
>on
>the connections. I have not observed any side-effects or bad behavior.
>The
>'partial send' actually completes. The application is 'best-effort'
>delivery on the network. I am continuing my verifications, but this
>appears
>to do the right thing for my use-case.
>
>Your thoughts? Corrections? Warnings?

Something else is wrong if you end up there... basically while you have a truncated send pending, there should be no way to send something new.

The code in the service loop enforces that; it won't call back as writeable while a truncated send is pending.  And you should only be sending something new (ending up at lws_issue_raw) in the writeable callback.

You are illegally sending something new outside of the writeable callback?  Or the library itself has a problem with its enforcement (I would have expected to get more complaints about hitting the assert...)

-Andy

>---8<-----------------------------------------------------------------------
>diff --git a/lib/output.c b/lib/output.c
>index b914f28..9e07ae5 100644
>--- a/lib/output.c
>+++ b/lib/output.c
>@@ -109,7 +109,8 @@ int lws_issue_raw(struct libwebsocket *wsi,
>unsigned
>char *buf, size_t len)
>                 wsi->truncated_send_len +
>                 wsi->truncated_send_offset))) {
>       lwsl_err("****** %x Sending new, pending truncated ...\n", wsi);
>-        assert(0);
>+        n = 0;
>+        goto handle_truncated_send;
>     }
>
>     m = lws_ext_callback_for_each_active(wsi,
>---8<-----------------------------------------------------------------------




More information about the Libwebsockets mailing list