michallenc commented on PR #21477:
URL: https://github.com/apache/nuttx/pull/21477#issuecomment-6681518225
> > There seems to be a change of behavior compared to the previous version
as this patch breaks the following code we use in Modbus application:
> > ```c
> > int epollfd = epoll_create1(0);
> >
> > struct eserver eservers[state->nservers];
> > for (int i = 0; i < state->nservers; i++) {
> > eservers[i] = (struct eserver){
> > .type = EWAITER_SERVER,
> > .server = state->servers[i],
> > };
> > struct epoll_event ev = {
> > .events = EPOLLIN | EPOLLHUP,
> > .data.ptr = &eservers[i],
> > };
> > int ret = epoll_ctl(epollfd, EPOLL_CTL_ADD,
> > modbus_server_pollfd(state->servers[i]), &ev);
> > assert(ret == 0);
> > }
> >
> > while (!halt || !*halt) {
> > struct epoll_event rev;
> > int ret = epoll_wait(epollfd, &rev, 1, timeout);
> > ...
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > doesn't return at all. The fd obtained by `modbus_server_pollfd` is a
TCP socket.
> > If the same code is run with serial server (fd for `epoll` is created by
`eventfd(0,0)` and then `eventfd_write(s->efd, 42)` is called), then the
`epoll_wait` returns multiple times, not just once as before the patch.
>
> @michallenc Thanks for the report. I fixed the behavior regression.
>
> The issue was that rearming a delivered level-triggered node could consume
the synchronous readiness notification generated during the driver poll setup
and enqueue the node again immediately. This made eventfd report repeatedly
after a single eventfd_write(), and could also affect TCP socket rearming.
>
> I updated the epoll rearm path to suppress the synchronous setup-time
notification while keeping the pollfd armed for future lower-half
notifications. So a delivered node is rearmed, but it will not be reported
again until a new driver notification occurs.
Thank you. I won't be able to test until Monday morning though, hope that's
ok.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]