nRF9160 offloaded poll() is incompatible with other Zephyr file descriptors (e.g. eventfd)

[mniestroj]

The big advantage of using poll() in application is the possibility to listen for multiple events at once such as:

- incoming traffic on BSD socket,
- incoming traffic on other socket type (e.g. pipe, socketpair),
- some event from other application thread/component using eventfd(),
- some timeouts using timerfd (not implemented in Zephyr yet, but it seems just a matter of time).

Current implementation of offloaded poll() for nRF91 modem sockets uses nrf_poll() underneath. This means that only modem sockets (file descriptors) are handled using such poll() call (and most mechanisms mentioned above do not). This is enough only for some simple usage, but is very limiting when application requires some complex behavior based on other application threads or traffic from other network interfaces.

We need to have for example some callback based mechanism for getting notifications from nRF sockets. That way those notifications can be easily integrated with Zephyr native poll() mechanism, which handles all possible socket types and allows implementation of much more advanced application code and possibly integration with higher number of existing POSIX-compatible libraries.

[mniestroj]

Didrik Rokhaug What is the status of this feature request? Any update/progress on that? See https://github.com/golioth/golioth-zephyr-sdk/pull/298 for our efforts to workaround this.

[Didrik Rokhaug]

Hi,

I have shared your workaround with the developers, but I haven't heard back from them yet.

Unfortunately, I don't think there has been any major progress on the topic.

Best regards,

Didrik

[ClemensG]

Hi,

I just stumbled across the same issue with he simple task of having a single socket where I want to wait for either data coming from the socket or an other (timely woken up) thread sending data through this socket. I guess this is a very common task in IoT devices.

Besides the fact, that BSD sockets never mixed well with threads (IMHO that was a good thing back in the old unix days where everything was a file and IPC was done using pipes and socketpairs,...) Zephyr has chosen to go this way. And I also assume that sockets are not thread save (having one thread blocking/polling for receive and an other thread sending through it).

I hope I am missing something but currently it seems the only way to achieve this behavior is by calling poll with timeouts, right? Somehow this feels really wrong as everything else is event based and the nrf9160 is meant to be low power and to keep the CPU in sleep for as much as possible. Without having looked into it I would guess that the modem causes an IRQ when when data is available and it would be easy for the scheduler to wakeup a thread (writing data to a queue/fifo or whatever).

So my questions: Is there any way of achieving this? I do see no way of how to do this with the event_manager? I would still either need to poll with timeout (to generate an event) so I can interleave rx and tx or being allowed to use different threads to act on the socket.

If timeout polling is the only way, my wish list would be:
- At least document this (non-)behavior. I took me quite a while figuring out what was going on (or not). It's  misleading having a posix interface while not acting like a posix interface. To be honest I was really disappointed  here: Isn't this functionality the key point of the nrf9160? At least having a way of keeping the cpu in sleep and waking up and acting on network or external events? Without polling!
- Please get at least eventfd or socketpair to be usable in parallel with network sockets in poll
- Alt: provide a other way of handling network data, maybe outside the socket world using OS primitives the better suited for use with multithreading (queues/fifos/...)

Regards,

Clemens

PS: Sorry if that sounds like a complain. I am just hitting one thing after the next in the software/sdk/zephyr at something I thought would be a an easy/fast thing to accomplish.

[Didrik Rokhaug]

Unfortunately, nothing much has happened yet.

But I have been told by our developers that they will start looking at it soon.