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

andy at warmcat.com andy at warmcat.com
Thu Jun 24 04:51:01 CEST 2021



On June 24, 2021 2:39:41 AM UTC, Felipe Gasper <felipe at felipegasper.com> wrote:
>
>
>> On Jun 23, 2021, at 10:20 PM, Felipe Gasper <felipe at felipegasper.com>
>wrote:
>> 
>> 
>> 
>>> 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:
>>>> Hello,
>>>> 
>>>> 	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!
>
>I got:
>
>perl: /home/pi/code/libwebsockets/lib/plat/unix/unix-service.c:153:.
>_lws_plat_service_tsi: Assertion `"no native poll" == NULL' failed.
>
>There are several poll() calls in the code; I assert()ed before them
>all then ran my code, and I got the above. When I comment out the
>assert things run normally; thus, I think this is the only problematic
>poll() call.

Well, that is proving what you have been saying then... can you get a backtrace to see how it got there?

The default poll loop presents as a participant in the event lib stuff, it has its own event lib ops and the context has to pick one at init time.  So it is a mutually exclusive thing, if you set your event lib ops, no normal way to reference the default one.  Something might call it directly I guess.

-Andy

>Of note: this is race-prone; on some runs of my little test
>program--which just connects to ws://echo.websocket.org and
>interconnects with stdin/stdout--I still see the poll()s, but they
>don’t seem to stall anything.
>
>-F


More information about the Libwebsockets mailing list