suspected bug in devpoll

[Arne Jansen]

As a workaround I now set devpoll_events to 1. This fixes the issue, though
it might slightly impact the performance.
Nevertheless, if someone can point me to a clean way to fix this, I'd give
it a try.

-Arne

On 02/16/2015 03:46 PM, Arne Jansen wrote:
> Hi,
> 
> I suspect a bug in the devpoll implementation. What I see is this:
> 
> recv() failed (134: Transport endpoint is not connected) while reading response
> header from upstream
> 
> truss (solaris) tells me that nginx has done a connect() = EINPROGRESS, directly
> followed by a read() on that socket, getting the ENOTCONN error.
> 
> What I suspect is as follows:
> I have two fds waiting for an event. Both get ready at the same time.
> ngx_devpoll_process_events fetches both from the kernel. While handling the
> first event, the second fd gets closed, reopened and connected (with
> EINPROGRESS). Afterwards, ngx_devpoll_process_events handles the already
> received event for the other fd. This leads to a read() call even though the
> socket is not connected yet.
> What I'm missing is code in ngx_devpoll_del_event that deletes revents from
> the global event_list, but I'm not sure if that's the right way to approach
> this and how it is supposed to synchronize with ngx_devpoll_process_events.
> 
> Thanks,
> Arne