[Libwebsockets] EAGAIN on recv() call for websocket (1.4 server application)

Mark Likness likness at gmail.com
Fri Sep 18 21:09:10 CEST 2015

I have a 1.4 libwebsockets server up and running using *external* polling
in a single thread. I have some traditional network sockets in the same
polling loop that's used for the websockets. This works very nicely most of
the time but occasionally I get a "error on reading from skt" log message
and a subsequent forced websocket close (in
I have confirmed the error is EAGAIN - basically the socket indicated it
had a POLLIN event during the poll() call but by the time the recv() call
was made the socket would have blocked (i.e., it no longer has data ready
to read).

In my single thread, I have a poll() call that blocks forever until there's
something to do on the websockets and traditional network sockets being
monitored. If an event comes in for one of my network sockets, I save the
data off and execute a libwebsocket_callback_on_writable() call so that it
can be forwarded out a websocket (in the callback). I then make a call to
libwebsocket_service() with a 0 timeout so that the callback can occur (if
I don't have this service call, it doesn't happen). If an event comes in
for a websocket, I pass it off with libwebsocket_service_fd() and let the
library handle it.

I make no other calls to _service() APIs in the thread. In other words, I'm
not in a tight loop calling the libwebsocket_service() function given I'm
using external polling.

Am I misusing the library to cause the recv() error on the socket? I've
done a little research to try to understand when/how a socket might report
POLLIN and then not have data when a recv() is done but not seeing too much
that leads me to a solution.

*After reading list traffic posted a while back by Bruce Perens, I'm
wondering if this could be a side effect (lost events) related to clearing
revents on the wrong file descriptor?*Any thoughts or assistance are
appreciated.  Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libwebsockets.org/pipermail/libwebsockets/attachments/20150918/a0213279/attachment.html>

More information about the Libwebsockets mailing list