libubox: How to terminate uloop orderly?
Alexandru Ardelean
ardeleanalex at gmail.com
Tue May 17 02:37:00 PDT 2022
On Tue, May 17, 2022 at 12:06 PM Koch, Alexander via openwrt-devel
<openwrt-devel at lists.openwrt.org> wrote:
>
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> ---------- Forwarded message ----------
> From: "Koch, Alexander" <akoch at initse.com>
> To: "openwrt-devel at lists.openwrt.org" <openwrt-devel at lists.openwrt.org>
> Cc:
> Bcc:
> Date: Tue, 17 May 2022 09:04:13 +0000
> Subject: libubox: How to terminate uloop orderly?
> Hi openwrt-devel,
>
> I'm writing a small daemon in C that talks to a specific IC and shall offer its
> functionality to other OpenWRT components via ubus.
>
> It spawns a separate pthread for all ubus related things, which ends up calling
> `uloop_run()`. So far everything works fine and I can see all objects exposed by
> my daemon on the bus.
>
> The issue I'm facing now is that I cannot seem to find a way of orderly shutting
> down the daemon, as the thread calling `uloop_run()` never returns from it. I've
> tried calling `uloop_end()` as well as replacing `uloop_run()` by
> `uloop_run_timeout(10)` but that didn't help.
I never thought/knew that uloop_run() & threads mixed well.
I never tried it too much either.
I always thought of uloop_run() being the main process loop and then
"maybe" starting some threads from there.
And I think uloop is kind of designed to be more single-process than
multi-process.
So, if you have one uloop somewhere and try to do some uloop calls in
a thread, it's kind of race-y and potentially buggy.
Also because they work on the same main loop data.
>
> So I'm wondering: what is the correct way to terminate the uloop?
>
> One thing that does seem to work is sending the thread a SIGTERM via
> `pthread_kill()`. But that makes `uloop_run()` return a non-zero value (15) and,
> as signals are delivered to the entire process, can have side-effects on other
> parts of the daemon, so I'd prefer to avoid this method.
>
>
> Thanks in advance for any hints!
>
>
> Best regards,
>
> Alex
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list