[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 02:13:49 PST 2023


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.

I suggest creating another function that will do this:

/* call this for read ALL events on ctx->sock.fd when not using uloop
 * after polling fd manually
 */
static inline void ubus_handle_events(struct ubus_context *ctx)
{
	ctx->cancel_poll = false;
	ctx->sock.cb(&ctx->sock, ULOOP_READ);
}

This idea comes from existing not exposed functionality of the function that does the polling by itself and then processes all messages:

void __hidden ubus_poll_data(struct ubus_context *ctx, int timeout)
{
	struct pollfd pfd = {
		.fd = ctx->sock.fd,
		.events = POLLIN | POLLERR,
	};

	ctx->cancel_poll = false;
	poll(&pfd, 1, timeout ? timeout : -1);
	ubus_handle_data(&ctx->sock, ULOOP_READ);
}

Instead of letting it do the polling we will do it our-self.

Please, review and advice.

A few words regrading the intention of this add-on: 
I am using the system that has a few different fds that are being polled and events on each are processed.
Sometimes there are more work on the fds, so processing ubus events take a lot of time with ubus_handle_event.
Additionally due to previous code that sets up ubus object ctx->cancel_poll becomes true. 

______________________________________________________________________
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 106-ubus_handle_events.patch
Type: text/x-patch
Size: 802 bytes
Desc: 106-ubus_handle_events.patch
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20230213/b3ea4a43/attachment-0001.bin>


More information about the openwrt-devel mailing list