[Libwebsockets] Bug? LWS-native poll() amidst custom polls
andy at warmcat.com
Thu Jun 24 17:44:41 CEST 2021
On 6/24/21 4:33 PM, Felipe Gasper wrote:
>> On Jun 24, 2021, at 8:38 AM, Andy Green <andy at warmcat.com> wrote:
>> On 6/24/21 11:50 AM, Felipe Gasper wrote:
>>>> On Jun 24, 2021, at 1:08 AM, andy at warmcat.com wrote:
>>>> Yes, he services ripe timeouts too. Once you confirmed the example works just follow it (as far as possible, the actual custom loop you want to work with might not be so nice).
>>> Yeah in this case the custom loop is a library like libev, where you don’t actually poll() manually. So I had to “translate” from that example.
>> Right... one advantage of reusing the event lib ops for this is that all the existing support for things like libev uses the same ops. So if you have to, eg, make the scheduled event timer for libev, specifically that already exists in event lib ops form for reference
>> ...it also means there are definitely enough hooks in the ops struct to do anything any other event lib needed.
> I saw this, yeah, but lws_ev_hrtimer_cb uses __lws_sul_service_ripe(); it wasn’t clear what the relationship is between that function and lws_service_adjust_timeout().
The latter calls through to __lws_sul_service_ripe() if you are changing
code in the custom loop to adjust the poll timeout.
> I don’t know if there’s any advantage to this for existing use cases, but would it be apropos to alter the native libev integration to use the custom API? Effectively making that libev integration itself a “minimal example”? (Maybe libuv et al. as well, though I know libuv presented additional special-case problems.)
There's no gap between those two things already. The event lib plugins
are built as user code outside of the library, and expose the event lib
ops struct via a lws_plugin_evlib_t, same as your custom implementation does
So if you need to cooperate with a generic libev application, you can
build the existing lws libev event library code as-is in your
application, and then use the custom init to point to its ops struct at
context creation time as you are doing for your custom version.
Same goes for libuv / libevent / glib / sdevent / uloop cases where the
suitable support already exists, you can bring them into your app and
tell the context creation to use them by pointing to the right
It's only for cases where it's really a custom event loop and not an
already supported event lib that you need to get your hands in the
custom stuff and wire it up. Otherwise you can pass in an existing
lws_plugin_evlib_t * at context creation time.
More information about the Libwebsockets