[FEATURE] Polling support for Unix datagram sockets

[michallenc]

Is your feature request related to a problem? Please describe.

This is a followup of !16555 that solved the issue of non working DGRAM sockets.

Describe the solution you'd like

Polling for Unix datagram sockets (SOCK_DGRAM) is currently not implemented. The implementation to local_netpoll.c seems pretty straightforward (at least for POLLIN), just create receiver if it doesn't exist (default state for the datagram, basically the same as in psock_dgram_recvfrom and call file_poll. The behavior of poll is still not as expected though, because it returns POLLHUP right after the poll is called. But this event should not return on datagram sockets as they are not connection oriented.

This bring us back to the same issue @Cynerd already faced with stream sockets in #14667. NuttX sockets are implemented with fifos and pipes, but the expected behavior of local sockets (both stream and dgram) is a bit different from pipes.

diff --git a/net/local/local_netpoll.c b/net/local/local_netpoll.c
index e68833aa9a..264c59c28a 100644
--- a/net/local/local_netpoll.c
+++ b/net/local/local_netpoll.c
@@ -161,7 +161,29 @@ int local_pollsetup(FAR struct socket *psock, FAR struct pollfd *fds)
 
   if (conn->lc_proto == SOCK_DGRAM)
     {
-      return -ENOSYS;
+      if (conn->lc_infile.f_inode == NULL)
+        {
+          ret = local_create_halfduplex(conn, conn->lc_path, conn->lc_rcvsize);
+          if (ret < 0)
+            {
+              nerr("ERROR: Failed to create FIFO for %s: %d\n",
+                   conn->lc_path, ret);
+              return ret;
+            }
+
+          /* Open the receiving side of the transfer */
+
+          ret = local_open_receiver(conn, false);
+          if (ret < 0)
+            {
+              nerr("ERROR: Failed to open FIFO for %s: %d\n",
+                   conn->lc_path, ret);
+              local_release_halfduplex(conn);
+              return ret;
+            }
+        }
+
+      return file_poll(&conn->lc_infile, fds, true);
     }
 
 #ifdef CONFIG_NET_LOCAL_STREAM
@@ -310,7 +332,7 @@ int local_pollteardown(FAR struct socket *psock, FAR struct pollfd *fds)
 
   if (conn->lc_proto == SOCK_DGRAM)
     {
-      return -ENOSYS;
+      return file_poll(&conn->lc_infile, fds, false);
     }
 
 #ifdef CONFIG_NET_LOCAL_STREAM

The implementation of polling for DGRAM would probably require the rewrite of local sockets and reimplementation with internet socket code base instead of fifos/pipes.

Describe alternatives you've considered

No response

Verification

• I have verified before submitting the report.

[xiaoxiang781216]

Is your feature request related to a problem? Please describe.

This is a followup of !16555 that solved the issue of non working DGRAM sockets.

Describe the solution you'd like

Polling for Unix datagram sockets (SOCK_DGRAM) is currently not implemented. The implementation to local_netpoll.c seems pretty straightforward (at least for POLLIN), just create receiver if it doesn't exist (default state for the datagram, basically the same as in psock_dgram_recvfrom and call file_poll. The behavior of poll is still not as expected though, because it returns POLLHUP right after the poll is called. But this event should not return on datagram sockets as they are not connection oriented.

we can hack fifo/pipe to change the behavior a little bit, actually the hook already exist:
https://github.com/apache/nuttx/blob/master/include/nuttx/fs/ioctl.h#L488-L493

This bring us back to the same issue @Cynerd already faced with stream sockets in #14667. NuttX sockets are implemented with fifos and pipes, but the expected behavior of local sockets (both stream and dgram) is a bit different from pipes.

The implementation of polling for DGRAM would probably require the rewrite of local sockets and reimplementation with internet socket code base instead of fifos/pipes.

this method need rewrite the whole local socket which is a huge work.

[michallenc]

Yeah, I know. I will likely get to this eventually, because it would be nice to have basic IPC with Unix datagrams, but it's not a priority.