As the man page explains:
"Specifying a timeout of zero causes poll() to return immediately,
even if no file descriptors are ready."
The use of 0 as timeout could cause libubus to busy loop if the
socket was non-blocking. For blocking sockets, this was less
apparent as the subsequent read() would then block.
Signed-off-by: Karl Vogel <karl.vogel@gmail.com>
Append ubus notification messages to the tail of the pending list
so they're processed in the order as they're put onto the pending list
Signed-off-by: Xinxing Hu <xinxing.huchn@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
The value from getglobal wasn't being removed from the stack,
resulting in an ever growing stack in the ubus event handler.
Signed-off-by: Karl Vogel <karl.vogel@gmail.com>
Signed-off-by: Hans Dedecker <dedeckeh@gmail.com>
ubus_connect_ctx() is equivalent to ubus_connect() but accepts a
pointer to a previously allocated ubus_context struct.
ubus_shutdown() is made available as an alternative to ubus_free()
to clean up contexts initialised by ubus_connect_ctx().
Signed-off-by: Delio Brignoli <dbrignoli@audioscience.com>
This fixes build warning:
/ubus.git/examples/server.c: In function 'test_hello_reply':
/ubus.git/examples/server.c:69:6: error: ignoring return value of 'pipe', declared with attribute warn_unused_result [-Werror=unused-result]
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
__init has a naming collision with C++ and prevents ubus_common.h
from being included. Instead, use __constructor as defined from
libubox.
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Context: 1 loop with a single ubus_invoke() that times out calls
uloop_end() which ends the loop, and thus ends the application.
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Set ctx->msgbuf.data to NULL during the call. If ctx->msgbuf is needed
during the call, a new buffer will be allocated. If not,
ctx->msgbuf.data is restored to the previous value afterwards
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
Client creates a string "1 2 3 ... 10000 ...", sends it to the server
along with the maximum number in the string.
Server creates another string like the client sent.
It validates it and, returns strcmp()'s result.
This is loop-ed every 2 seconds.
The realloc is problematic mostly with large packets, as the pointer changes
so what eventually gets free'd is invalid.
Note that ub ptr param in the call will be passed on to a ubus_msg_free(),
right after ubus_msg_ref() finishes.
This bug stayed hidden the same way as the bug in libubus writev_retry().
Since the write/sendmsg function can send about ~200k the ubus_msg_enqueue()
call does not get triggered.
Seems this bug stayed hidden for a while, because the write/sendmsg function
can send up to ~200k in one send, so it looked at first why there was
some data mismatch.
