Avoid calling lws_write() from threads other than the service thread, as
this might not be thread-safe. Instead store the values used for the
HTTP response headers in the websocket_output, then trigger a "writable"
callback, and finally do all the lws_write() calls from the service
thread.
Reported in #1624
Change-Id: Ifcb050193044e5543f750a12fb44f5e16d4c0a08
(cherry picked from commit b207d0c586)
Removes one level of indentation for prettier code. Functional no-op.
Change-Id: I5f5528944f144499540f34bc1f322d00c9454fa6
(cherry picked from commit cb9ec2abf9)
Make the websocket_conn_init() function return an error code, and delay
the initialization after we cannot fail. And otherwise return -1, such
as when we cannot initialize the HTTP nor SSL connection.
Change-Id: I0facd53560fdb06678d7df9775be277e5c4b2cae
Warned-by: coverity
Sequence of events:
1) HTTP request is being handled in worker thread by calling the handler
func() from within websocket_process().
2) Handler func generates output, queues it up, and requests a
`writeable` callback from within websocket_write_raw().
3) Main LWS thread triggers writeable callback and calls
websocket_dequeue().
4) Output is given to LWS still within the main LWS thread, and finally
lws_http_transaction_completed() is called to release the connection
and ready it for the next HTTP connection.
5) LWS internally cleans up the connection and frees the user context
(our `wc` struct).
6) The worker thread wakes up and continues to use the now invalid `wc`
in order to clean up after it has done its job. Boom.
The solution is to handle the `drop protocol` callback, which is
triggered by LWS in the main LWS thread in step 4 from within
lws_http_transaction_completed(). We call our own connection cleanup
function websocket_conn_cleanup() which blocks until all jobs are
removed from `wc` (step 6) and only then continue, allowing LWS to
safely free the struct.
Change-Id: I596a98e9b552a96aef259f4523f16fa63c287ef4
Richard Fuchs
Guillem Jover