[Libwebsockets] Fast loop of LWS_CALLBACK_GET_THREAD_ID events.
wonder.mice at gmail.com
Sat Apr 25 00:46:38 CEST 2015
See also that issue, looks similar:
I suspect, that it's related to the fact that when OpenSSL wants to
READ, libwebsockets will add the socket to WRITE set anyway. And since
socket IS writable (it's just nothing for OpenSSL to write), event
loop will be triggered. This will continue forever in busy loop until
there is actually something to read.
I'm digging into this right now since I observe that while connecting
to the server. Your issue is about the disconnect, but I think the
root cause is similar - calling libwebsocket_callback_on_writable()
when it shouldn't be called.
On Fri, Apr 24, 2015 at 2:40 PM, Bruce Perens <andy.green at linaro.org> wrote:
> Looking at parser.c, it gets LWS_WS_OPCODE_07__CLOSE and goes to
> process_as_ping. This code wants to send a pong, and does an internal
> libwebsocket_callback_on_writable(). Perhaps the writable callback isn't
> being handled properly internally, or my client is gone, it didn't wait for
> close to be acknowledged, there is nothing to send a pong to.
> We then return from libwebsocket_service() immediately in a loop for 60
> seconds, asking for the thread ID each time around the loop.
> For now, I just kludged the code to not call
> libwebsocket_callback_on_writable() if wsi->u.ws.opcode is
> LWS_WS_OPCODE_07__CLOSE. That is enough to keep the loop from happening.
> But I don't know what I'm doing with this code. No doubt there is a better
> On Fri, Apr 24, 2015 at 2:16 PM, Bruce Perens <bruce at perens.com> wrote:
>> I turned on debugging messages in libwebsockets. This is what I get:
>> [1429909911:8716] PARSER: server sees client close packet
>> Change poll FD fd = 8, events = 5
>> [1429909911:8716] DEBUG: libwebsocket_read: read_ok At
>> this point, the libwebsocket_service() loop starts eating the CPU.
>> [1429909971:8718] INFO: service_fd: closing due to 0 length read 60
>> seconds later, we realize the connection is gone.
>> [1429909971:8718] DEBUG: Close and handled
>> [1429909971:8718] DEBUG: close: just_kill_connection
>> [1429909971:8719] INFO: remove_wsi_socket_from_fds: wsi=0x1716e00, sock=8,
>> fds pos=2
>> Delete poll FD, count = 1 fd = 8, events = 0
>> [1429909971:8719] DEBUG: calling back CLOSED
>> On Fri, Apr 24, 2015 at 11:13 AM, Bruce Perens <bruce at perens.com> wrote:
>>> My server currently catches LWS_CALLBACK_GET_THREAD_ID and returns
>>> pthread_self(). Currently, it never calls
>>> Using either the released version or a pull from git today, a
>>> libwebsocket_service() loop with a long delay eats the CPU while a socket is
>>> closing. This is what I am seeing:
>>> Add poll FD, count = 1 fd = 6, events = 1 Start of serving a few
>>> files via HTML. Lots of LWS_CALLBACK_GET_THREAD_ID events happening here.
>>> Add poll FD, count = 2 fd = 7, events = 1
>>> Add poll FD, count = 3 fd = 8, events = 1
>>> Add poll FD, count = 4 fd = 9, events = 1
>>> Delete poll FD, count = 3 fd = 7, events = 0
>>> Delete poll FD, count = 2 fd = 8, events = 0
>>> Delete poll FD, count = 1 fd = 9, events = 0
>>> Add poll FD, count = 2 fd = 8, events = 1 Start of Websocket
>>> Connection with protocol: radio-server-1 path: /foo
>>> Change poll FD fd = 8, events = 5 Service is in closing
>>> state, CPU utilization goes to 100%, continuous LWS_CALLBACK_GET_THREAD_ID
>>> events here.
>>> Delete poll FD, count = 1 fd = 8, events = 0 Service is closed, CPU
>>> utilization goes low again.
>>> Websocket connection closed.
>>> Am I providing the wrong information to the LWS_CALLBACK_GET_THREAD_ID
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets