[OpenWrt-Devel] Mismatch in ubus / uloop options

Karl Vogel karl.vogel at gmail.com
Mon Dec 7 04:41:19 EST 2015

In ubus_reconnect, the ctx->sock.fd is created and set to non-blocking mode:

fcntl(ctx->sock.fd, F_SETFL, fcntl(ctx->sock.fd, F_GETFL) | O_NONBLOCK |


However, further in the call stack, the socket will get added to uloop via
ubus_add_uloop with the flag ULOOP_BLOCKING set.


ie when called from ubus_complete_request on an !registered ctx->sock, the
ubus_add_uloop is done:


The uloop function assumes a socket is blocking by default and will never
make a socket blocking again, it will only turn it to non-blocking if
ULOOP_BLOCKING isn't set. This caused a busy loop in some daemons that had
their socket set to non-blocking due to another issue, ie. poll using 0 as
infinite instead of -1, for which I submitted a fix earlier.

I wonder if it wouldn't be better to have uloop set the socket flags in all
cases? Currently it "assumes" the socket is blocking and if ULOOP_BLOCKING
is passed, it will set it to non-blocking, but it won't do the other way
round. Though that might have some impact on daemons that think the socket
is non-blocking while it will be turned into blocking if this is changed.
So not sure what the best way to go about this one is?!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20151207/43e6d1cc/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list