[Libwebsockets] Bug? LWS-native poll() amidst custom polls

Andy Green 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
>>
>> https://libwebsockets.org/git/libwebsockets/tree/lib/event-libs/libev/libev.c?h=main#n32-48
>>
>> ...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

https://libwebsockets.org/git/libwebsockets/tree/lib/event-libs/libev/libev.c?h=v4.2-stable#n438

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

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.

-Andy

> -F
> 


More information about the Libwebsockets mailing list