Hi,
I know a POLLOUT would be the right thing if I am interested in knowing when the connection is complete, but I don't care :) I _could_ add a POLLOUT just to "work around" this error however I prefer not. We only care about when there is data available, so POLLIN is correct, and it works on Linux and used to work on NuttX. Now I will never get any POLLIN event no matter how much data is sent from the other side. Regards Marten Svanfeldt ________________________________ From: 汪博文 <bowenwa...@gmail.com> Sent: Tuesday, September 19, 2023 3:21:34 PM To: dev@nuttx.apache.org Subject: Re: epoll oddities following setup/teardown optimizations Hi, Marten I found some information about the epoll problem with the nonblocking local socket. From https://man7.org/linux/man-pages/man2/connect.2.html, we can see: EINPROGRESS The socket is nonblocking and the connection cannot be completed immediately. (UNIX domain sockets failed with EAGAIN instead.) *It is possible to [select(2)](https://man7.org/linux/man-pages/man2/select.2.html <https://man7.org/linux/man-pages/man2/select.2.html>) or [poll(2)](https://man7.org/linux/man-pages/man2/poll.2.html <https://man7.org/linux/man-pages/man2/poll.2.html>)* * for completion by selecting the socket for writing.* After [select(2)]( https://man7.org/linux/man-pages/man2/select.2.html) indicates writability, use [getsockopt(2)](https://man7.org/linux/man-pages/man2/getsockopt.2.html) to read the SO_ERROR option at level SOL_SOCKET to determine whether connect() completed successfully (SO_ERROR is zero) or unsuccessfully (SO_ERROR is one of the usual error codes listed here, explaining the reason for the failure). Use POLLOUT event to poll the non-connected nonblocking socket seems the right way instead of using POLLIN event. Could you try this ? Regrads Wang Bowen Mårten Svanfeldt <marten.svanfe...@actia.se> 于2023年9月19日周二 19:17写道： > Hello, > > > I did some quick checking and it does indeed solve my problem. Do you want > me to give a review/ack on the github PR? I do have an account there with > id "thebolt" (but it is not yet linked to my current employers email from > which I am writing this) > > > I do however still have some epoll problems, also related to this change, > and now it is together with unix local (stream) socket. > > > The setup is as follows, I have to tasks, taskA and taskB. > > > taskA does setup a new local socket, does listen (blocking) followed by > accept (blocking) followed by "simple" poll+write/read > > taskB does socket(), make nonblock, connect() and then adds the socket fd > to an epoll fd with EPOLLIN only. > > > epoll_ctl(..EPOLL_CTL_ADD..) does poll setup, which in this case is > local_pollsetup (in local_netpoll.c). The connection is in state > LOCAL_STATE_CONNECTING (taskA didn't run accept yet) so the poll is setup > as an "event poll". > > > When taskA calls "accept" it eventually will perform a poll_notify(... > EPOLLOUT), but ask taskB only specified EPOLLIN it will be ignored, the > epoll not waken up, revents still set to 0 and the fd stays on the > setup-list inside the epoll, meaning it will never do another poll setup on > it, even though the socket itself changed state internally so that the next > call to local_pollsetup would setup the polling differently. > > > > In principle I wonder if you don't have to move from "setup" to "teardown" > list (so that the fd is re-setup the next epoll_wait) not only on > successful poll_notify but on _any_ poll_notify independent of if > (filtered) revents is changed or not. Otherwise internal state changes in > the underlying driver/module will never be detected and pollsetup not > re-ran when needed. > > > Regards > > Marten Svanfeldt > > ________________________________ > From: 汪博文 <wangbow...@xiaomi.com> > Sent: Tuesday, September 19, 2023 12:11:27 PM > To: Mårten Svanfeldt > Cc: dev@nuttx.apache.org > Subject: RE: epoll oddities following setup/teardown optimizations > > Hi, > > I has a fix fs_epoll: add critical section for teardown process and reset > the eph… by CV-Bowen · Pull Request #10706 · apache/nuttx (github.com)< > https://github.com/apache/nuttx/pull/10706> about this problem. > But I couldn’t find your GitHub ID, so I’m notifying you through email. > Could you try this PR and check if this PR resolves your problem ? > > Regards > Wang Bowen > #/******本邮件及其附件含有小米公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from > XIAOMI, which is intended only for the person or entity whose address is > listed above. Any use of the information contained herein in any way > (including, but not limited to, total or partial disclosure, reproduction, > or dissemination) by persons other than the intended recipient(s) is > prohibited. If you receive this e-mail in error, please notify the sender > by phone or email immediately and delete it!******/# >
