Can I wakeup mongoose w/o a connection context?

[TomzBench]

I am using mongoose with the Zephyr RTOS environment. Zephyr has IPC schemes that cannot be polled like a normal kernel socket. (Zephyr uses entirely unique polling infrastructure when working between sockets or any thing you might want to poll, which is very annoying.)

My workaround is I wake mongoose when I have a zephyr style message to send to the mongoose task. My mongoose callback will poll the zephyr style polling infrastructure when it is woken and process the zephyr style ipc.

However, this ipc scheme is not neccessarily associated with a client connection. So i passed the client id as 0, and so the waker sees this 0 connection and decides not to wake. This is unfortunate for me.

I understand we dont want to call the mongoose callback with a NULL connection as this might be breaking behavior. But it is worth considering this use case and perhaps a new event can be allowed for a special kind of wake that does not associated with a connection. This would prevent breaking code that relies on a connection being present when it is woken

[scaprile]

We know Zephyr, we support Zephyr.
What exactly is what you're trying to do, why, and exactly what fails; please describe your problem, not the workaround you think is your solution

[TomzBench]

I want to call mg_wakeup like this.

mg_wakeup(mgr, 0, NULL, 0);

The 0 in the second argument means mongoose will not wake me.

[TomzBench]

are you asking why I want to do that? so i can call zephyrs k_poll in the same thread that is running mongoose. More details than that should not be necessary i would think.

[scaprile]

Honestly.
I don't understand what you are doing, less why you want to do that.
I don't understand what you mean by "we dont want to call the mongoose callback with a NULL connection", there is no Mongoose callback to call, nor a way for you to pass or not pass a connection, you just call the manager by calling mg_mgr_poll() and it takes care of everything else. The manager itself will call select() or poll(), depending on how you configure it. If, for some reason, you don't want to do that, you need to re-write the poll loop for your particular function call.

mg_wakeup is used in multithreading environments within that frame; https://mongoose.ws/tutorials/core/multi-threaded/

If you explain what you want to do and provide an example, we'll be more than glad to help you out to find the best way to do it.
If you provide us a compelling use case, we may write a specific poll loop for Zephyr
Otherwise, I can't have an opinion on something I can't grasp.
If you are a paying customer, please contact Support as per your contract, so we can help you better.

Please see our documentation, and follow the guidelines in our tutorials.
Thank you.

PS: Closing this, you can still write, it can be opened again or moved to an issue if necessary.

[scaprile]

Short link: 12f1864

My thoughts:
Looks like the specific event loop we've been discussing. That extra "socket" can reuse the "pipe" variable, and that extra boolean c->is_eventfd is quite proprietary, I wonder if that can be avoided.
event_fd is something that also exists in Linux, though according to the docs and what I understand from the OP description, in Zephyr case, those need a different poll call, while Linux supports them. It smells like signals, though... I guess we can live with them inside an RTOS

What I would do, though, is to avoid an extra API call, and re-use the mg_wakeup API replacing the pipe with something like this.
It would also work for FreeRTOS (with its proper core code), and other RTOSes; while also avoiding the loopback interface.
@cpq ?

[TomzBench]

I did not like the is_eventfd at all, im not familiar enough with mongoose internals to avoid it though. Appreciate the review!

[scaprile]

Yeah, if I would include something like this, I would have two internals with a single API, the OS API would use the socket pipe and the RTOS flavor would use some other solution like this one.
We've internally discussed something like this before, but since we got no requests, it stayed as tech talk.

[scaprile]

(deleted the comment you wanted to be ignored)

[TomzBench]

sent quote request today. Please be gentle! :)