[Libwebsockets] lws_cancel_service() and libev

Olivier Langlois olivier at olivierlanglois.net
Sun Feb 9 23:31:19 CET 2020


I have found out that lws_cancel_service() wasn't cancelling foreign
loops.

To workaround this, here is what I had to do:

1. Create my loop outside lws and pass it through foreign_loops when
creating my lws_context
2. Handle LWS_CALLBACK_EVENT_WAIT_CANCELLED and call ev_break() from my
callback.

Maybe this is something that lws could handle itself. This is
definitely a call from the architect in chief but if I was to imagine
how it could be done, I would say:

a) Add a cancel operation to the event-libs ops
b) call the cancel operation from the roles/pipe code where
LWS_CALLBACK_EVENT_WAIT_CANCELLED is called.

Now fixing lws_cancel_service() for libev is causing another problem:

Exiting lws_service() with internal loop returns 0 whereas with any
other loop it returns 1:

       if (context->event_loop_ops->run_pt) {
                /* we are configured for an event loop */
                context->event_loop_ops->run_pt(context, tsi);

                pt->inside_service = 0;

                return 1;
        }

        n = _lws_plat_service_tsi(context, timeout_ms, tsi);

        pt->inside_service = 0;

        return n;
  
This is breaking examples code such as minimal-ws-client-echo.c if they
are used with a foreign loop:

        while (!lws_service(context, 0) && !interrupted)
                ;

Having to find those workarounds did again force me to study lws code
and this gave me few questions around lws_cancel_service().

- Why calling lws_cancel_service() from lws_create_context() to
initialize the protocols?
- Why not just calling lws_protocol_init() directly instead from
lws_create_context()?
- If protocols were initialized before exiting lws_create_context(),
the code wouldn't have to verify the protocol initialisation from
various points (such as in lws_client_connect_via_info())...




More information about the Libwebsockets mailing list