This block makes no sense, since busy is right next to it. Also, lock/unlock can be avoided as well. We can just call ngx_http_upstream_get_least_conn_peer() recursively and return its result. The nested call will assign the same pc->name.

@@ -103,7 +103,7 @@ ngx_http_upstream_get_least_conn_peer(ngx_peer_connection_t *pc, void *data)
 
     time_t                         now;
     uintptr_t                      m;
-    ngx_int_t                      rc, total;
+    ngx_int_t                      total;
     ngx_uint_t                     i, n, p, many;
     ngx_http_upstream_rr_peer_t   *peer, *best;
     ngx_http_upstream_rr_peers_t  *peers;
@@ -278,19 +278,7 @@ failed:
 
         ngx_http_upstream_rr_peers_unlock(peers);
 
-        rc = ngx_http_upstream_get_least_conn_peer(pc, rrp);
-
-        if (rc != NGX_BUSY) {
-            return rc;
-        }
-
-        ngx_http_upstream_rr_peers_wlock(peers);
-
-#if (NGX_HTTP_UPSTREAM_ZONE)
-        if (peers->config && rrp->config != *peers->config) {
-            goto busy;
-        }
-#endif
+        return ngx_http_upstream_get_least_conn_peer(pc, rrp);
     }
 
 #if (NGX_HTTP_UPSTREAM_ZONE)

I could swear I dropped this goto busy after your review in July. Anyways, fixed. Thanks for catching!

Regarding the lock/unlock optimization: it is a preexisting issue introduced to reduce the diff with our other repository. I can submit another PR addressing that, but I believe it would only complicate merges.

Indeed this part is the existing code. Agreed. Maybe later.

As was mentioned before, these fields are not needed in nginx open source. But I agree, at this point it's easier to keep them here than to add a compat section. Having said that, I think allocating an ngx_event_t object in a shared zone is not good anyway. We can later think about making it worker-local and removing it from here. Seems pretty simple.

Also, there's one case when the shared event leads to an actual segfault. On Windows, when more than 1 worker is configured, all those workers have ngx_worker == 0, which allows them to reuse the event object, which leads to a crash. Of course, having more than 1 worker on Windows makes no sense since only one of them works, but still the problem is there, and removing the event from shared zone will solve it.

I'm quite aware of the issue, and it's not that simple. Moving the event to worker-local memory doesn't solve that as long as there is an event and a pointer to it. Getting rid of the per-host ngx_event_t seems to be the best option, but it requires redoing the whole scheduling of resolve tasks and we still want to maintain some kind of worker affinity to be able to use ngx_resolver_t caches (that are not shared at the moment). At this point it becomes easier to add ngx_worker support on Windows :)

See my second (or third?) attempt to rework that: https://mailman.nginx.org/pipermail/nginx-devel/2023-February/NQSIPFNPTD4CDOLTGOHDWIMIHQ6DQY6S.html.

Indeed this part is the existing code. Agreed. Maybe later.