Hello Alexander, On Tue, 17 May 2022 12:37:00 +0300, Alexandru Ardelean <ardeleana...@gmail.com> wrote:
> On Tue, May 17, 2022 at 12:06 PM Koch, Alexander via openwrt-devel > <openwrt-devel@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" <ak...@initse.com> > > To: "openwrt-devel@lists.openwrt.org" <openwrt-devel@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. > > Despite the mentioned multi-threading problems with this approach one option to stop the uloop_run() call from another thread is by calling: uloop_handle_sigint(SIGTERM) But needs a patched libubox to get public access to this method, e.g.: diff --git a/uloop.c b/uloop.c index 8517366..b7cc764 100644 --- a/uloop.c +++ b/uloop.c @@ -402,7 +402,7 @@ static void uloop_signal_wake(void) } while (1); } -static void uloop_handle_sigint(int signo) +void uloop_handle_sigint(int signo) { uloop_status = signo; uloop_cancelled = true; diff --git a/uloop.h b/uloop.h index 36084f5..ab061a5 100644 --- a/uloop.h +++ b/uloop.h @@ -112,4 +112,7 @@ static inline int uloop_run(void) } void uloop_done(void); + +void uloop_handle_sigint(int signo); + #endif Regards, Peter > > > > Thanks in advance for any hints! > > > > > > Best regards, > > > > Alex > > > > _______________________________________________ > > openwrt-devel mailing list > > openwrt-devel@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel