In limit_req, auth_delay, and upstream code to check for broken connections, tests for possible connection close by the client did not work if the connection was already closed when relevant event handler was set. This happened because there were no additional events in case of edge-triggered event methods, and read events were disabled in case of level-triggered ones. Fix is to explicitly post a read event if the c->read->ready flag is set.
For connection close to be reported with eventport on Solaris, ngx_handle_read_event() needs to be called.
For new data to be reported with eventport on Solaris, ngx_handle_read_event() needs to be called after reading response headers. To do so, ngx_http_upstream_process_non_buffered_upstream() now called unconditionally if there are no prepread data. This won't cause any read() syscalls as long as upstream connection is not ready for reading (c->read->ready is not set), but will result in proper handling of all events.
If we need to be notified about further events, ngx_handle_read_event() needs to be called after a read event is processed. Without this, an event can be removed from the kernel and won't be reported again, notably when using oneshot event methods, such as eventport on Solaris. While here, error handling is also added, similar to one present in ngx_resolver_tcp_read(). This is not expected to make a difference and mostly added for consistency.
If an attempt is made to delete an event which was already reported, port_dissociate() returns an error. Fix is avoid doing anything if ev->active is not set. Possible alternative approach would be to avoid calling ngx_del_event() at all if ev->active is not set. This approach, however, will require something else to re-add the other event of the connection, since both read and write events are dissociated if an event is reported on a file descriptor. Currently ngx_eventport_del_event() re-associates write event if called to delete read event, and vice versa.
If, at the start of an event loop iteration, there are any timers in the past (including timers expiring now), the ngx_process_events() function is called with zero timeout, and returns immediately even if there are no events. But the following code only calls ngx_event_expire_timers() if time actually changed, so this results in nginx spinning in the event loop till current time changes. While such timers are not expected to appear under normal conditions, as all such timers should be removed on previous event loop iterations, they still can appear due to bugs, zero timeouts set in the configuration (if this is not explicitly handled by the code), or due to external time changes on systems without clock_gettime(CLOCK_MONOTONIC). Fix is to call ngx_event_expire_timers() unconditionally. Calling it on each event loop iteration is not expected to be significant from performance point of view, especially compared to a syscall in ngx_process_events().
Without explicit handling, a zero timer was actually added, leading to multiple unneeded syscalls. Further, sending GOAWAY frame early might be beneficial for clients. Reported by Sergey Kandaurov.
Unlike in 75e908236701, which added the logic to ngx_http_finalize_request(), this change moves it to a more generic routine ngx_http_finalize_connection() to cover cases when a request is finalized with NGX_DONE. In particular, this fixes unwanted connection transition into the keepalive state after receiving EOF while discarding request body. With edge-triggered event methods that means the connection will last for extra seconds as set in the keepalive_timeout directive.