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

Felipe Gasper felipe at felipegasper.com
Thu Jun 24 17:33:23 CEST 2021



> 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().

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

-F


More information about the Libwebsockets mailing list