[PATCH] ubus: added ubus_handle_events function that "guaranties" execution of all polled events

BOICHUK Taras taras.i.boichuk-ext at sagemcom.com
Mon Feb 13 06:11:38 PST 2023


Hi,

> You're already using a foreign event loop / IO notification mechanism, you
> already have means to determine socket read readiness. Invoking a library
> function that does it's own polling internally with arbitrary, uncontrollable
> timeouts does not seem like a good design.

Maybe, I don't get something right, but it seems like in my patch It does not
do any internal polling when calling ubus_handle_events. It will call ubus_handle_data
function, which is the command block ctx->sock.cb that will be executed with
ctx->cancel_poll set to false. The ctx->cancel_poll could be redundant in the loop,
because I don't see any way its state could be changed during the loop flow.

> It would be better to implement a function that simply keeps calling
> `get_next_msg(ctx, &recv_fd)` and `ubus_process_msg(ctx, &ctx->msgbuf,
> recv_fd);` until `get_next_msg()` yields false.

ubus_handle_data seems to do exactly what you've described, so is there any
other reason to implement separate function?

________________________________________
From: openwrt-devel <openwrt-devel-bounces at lists.openwrt.org> on behalf of Jo-Philipp Wich <jo at mein.io>
Sent: Monday, February 13, 2023 3:12 PM
To: openwrt-devel at lists.openwrt.org
Subject: Re: [PATCH] ubus: added ubus_handle_events function that "guaranties" execution of all polled events

[EXTERNAL]-Real sender is: openwrt-devel-bounces+taras.i.boichuk-ext=sagemcom.com at lists.openwrt.org

----------------------------------------------------------------------
Hi,

> In case of previous setup or calling flow ctx->cancel_poll is set to true
> function ubus_handle_event may process ONLY ONE request, though the comment
> says it processes events:
>
> /* call this for read events on ctx->sock.fd when not using uloop */ static
> inline void ubus_handle_event(struct ubus_context *ctx) {
> ctx->sock.cb(&ctx->sock, ULOOP_READ); }
>
> In case if I would manually poll the ubus fd and do not use uloop to poll
> it and after that it may process ONE event and the rest will be processed
> on the next loop cycle. I would like to have a function that guarantees
> that every request will be processed in a single call to
> ubus_haubus_handle_eventndle_event.

You're already using a foreign event loop / IO notification mechanism, you
already have means to determine socket read readiness. Invoking a library
function that does it's own polling internally with arbitrary, uncontrollable
timeouts does not seem like a good design.

It would be better to implement a function that simply keeps calling
`get_next_msg(ctx, &recv_fd)` and `ubus_process_msg(ctx, &ctx->msgbuf,
recv_fd);` until `get_next_msg()` yields false.

~ Jo

______________________________________________________________________
Ce courriel et les documents qui lui sont joints sont, sauf mention contraire, présumés de nature confidentielle et destinées à l'usage exclusif du ou des destinataire(s) mentionné(s). Si vous n'êtes pas le ou les destinataire(s), vous êtes informé(e) que toute divulgation, reproduction, distribution, toute autre diffusion ou utilisation de cette communication ou de tout ou partie de ces informations est strictement interdite, sauf accord préalable de l’expéditeur. Si ce message vous a été transmis par erreur, merci d’immédiatement en informer l'expéditeur et supprimer de votre système informatique ce courriel ainsi que tous les documents qui y sont attachés. En vous remerciant de votre coopération.

This email and any attached documents are, unless otherwise stated, presumed to be confidential and intended for the exclusive use of the recipient(s) mentioned. If you are not the recipient(s), you are informed that any disclosure, reproduction, distribution, any other dissemination or use of this communication or all or part of this information is strictly prohibited, unless agreed beforehand by the sender. If you have received this e-mail in error, please immediately advise the sender and delete this e-mail and all the attached documents from your computer system. Thanking you for your cooperation.



More information about the openwrt-devel mailing list