[Libwebsockets] Bug? LWS-native poll() amidst custom polls
felipe at felipegasper.com
Thu Jun 24 04:20:58 CEST 2021
> On Jun 23, 2021, at 9:52 PM, andy at warmcat.com wrote:
> On June 24, 2021 12:07:24 AM UTC, Felipe Gasper <felipe at felipegasper.com> wrote:
>> I’m working on a Perl binding to LWS
>> (https://github.com/FGasper/p5-Net-Libwebsockets … very much under
>> construction still!) and am seeing some weirdness where LWS still runs
>> its native poll() even though there is a custom event loop configured.
>> I’m attaching a Linux strace: you can see poll() amidst _newselect()
>> calls. Note the last in particular, where it waits 30 seconds … this is
>> the retry.secs_since_valid_hangup.
>> I’m inclined to think this is a LWS bug since “mixed” polling seems
>> like it shouldn’t happen, but just in case … is it possible I’m
>> “holding it wrong”?
> strace is a bit circumstantial... put an assert() on lws default poll() usage and see if that is actually involved.
> Strace is oblique enough that you might be seeing eg, libc blocking getaddrinfo() internal implementation or something else. 30s wait is what you might get on misconfigured dns resolver lookup.
That’s what I thought, too. To check it I altered my retry.secs_since_valid_hangup, and that last poll() changed accordingly. So there definitely seems to be something still giving LWS’s timeout to a poll() … which I assume is LWS’s native poll().
I’ll try the assert idea. Thank you!
> Also these newselects seem to be spinning rather than idling, if it's just reflects development didn't address it yet then no problem, but a real implementation should pick a big timeout number and ask lws to shrink it before entering the wait as shown in the minimal example.
That’s what I’m doing (see get_timeout() in Libwebsockets.xs), but I’ll check to see if that’s being used as I intend.
More information about the Libwebsockets