[OpenWrt-Devel] Question about conflict between ubus_invoke and uloop_run

XiaoFengMeng xiaofeng.meng at pfsw.com
Fri Apr 3 02:41:29 EDT 2015


HI Alexandru

Thanks so much for your reply!
In my case, the ubus_invoke will be called in a callback function which is in a separate thread, and uloop_run will be running in  main thread.
If I have to use ubus_invoke_async, then I feel that I have to use a lock to sync the call.

And I think you confirmed with an idea of mine:
if I want to use “ubus_invoke”,  “uloop_run” can’t be used at the same time,
or if I use uloop_run, I have to use ubus_invoke_async instread.

Is that right?

But I just got a tricky way of using ubus_invoke and uloop_run at the same time.
For the ubus context which is only used to call ubus_invoke as client, I set the registered of usock to true,
ctx->ubus->sock.registered = true;

actually this socket is not added to uloop in reality, I do this so that following code in ubus_complete_request function will not be executed.
And thus no conflict with uloop.
if (!registered) {
                uloop_init();
                ubus_add_uloop(ctx);
}

I experimented on this, it seems working well,
I like to know what’s your opinion on this?

Thanks!
/Kevin
From: Alexandru Ardelean [mailto:ardeleanalex at gmail.com]
Sent: 2015年4月3日 14:20
To: XiaoFengMeng
Cc: openwrt-devel at lists.openwrt.org
Subject: Re: [OpenWrt-Devel] Question about conflict between ubus_invoke and uloop_run

Hello Kevin,
As far as my understanding goes regarding ubus and uloop, they were not designed with threading in mind.
Also, as a general rule when using uloop, you wouldn't use threads, because races could occur (especially when doing ubus calls inside a thread) and the main uloop loop would terminate.

One general rule would be: you should not use ubus call in threads.
You could use ubus_invoke_async() instead of ubus_invoke().
It is a bit more work than just using ubus_invoke() but if you want thread-like behaviour, it could replace all the threads you're using.

So, is there a way to re-design your code without using threads and using ubus async calls ?


On Fri, Apr 3, 2015 at 5:24 AM, XiaoFengMeng <xiaofeng.meng at pfsw.com<mailto:xiaofeng.meng at pfsw.com>> wrote:
HI !
I am Kevin and learning the ubus code and got something that is confusing me very much in the code.

My question is regarding code in  ubus_invoke -> ubus_complete_request,

I can see that there are lots of uloop related code in  “ubus_complete_request”
if (!registered) {
                                uloop_init();
                                ubus_add_uloop(ctx);
}
….
while (!req->status_msg) {
                                bool cancelled = uloop_cancelled;

                                uloop_cancelled = false;
                                if (req_timeout) {
                                                timeout = time_end - get_time_msec();
                                                if (timeout <= 0) {
                                                                ubus_set_req_status(req, UBUS_STATUS_TIMEOUT);
                                                                break;
                                                }
                                }
                                ubus_poll_data(ctx, (unsigned int) timeout);

                                uloop_cancelled = cancelled;
                }

My question is why is uloop involved here?  uloop could be working in another thread and also listen on the same socket.
I idea that, before the ubus_invoke sends the request messge, it should disable the uloop for the current socket, so that code in uloop_run will not receive anything from the same socket.

Because after calling ubus_add_uloop(ctx), the uloop_run could also be receiving the response data
And this function could cause the uloop_run to quit the while loop.
How should I understand the logic here?

And How should I do if I want to call ubus_invoke as a client and use uloop_run as a server at  the same process?

Thanks very much!

Best regards
Kevin


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org<mailto:openwrt-devel at lists.openwrt.org>
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150403/0d30e5d0/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list