http.c: clear the 'finished' member once we are done with it

In http.c, the run_active_slot() function allows the given "slot" to make progress by calling step_active_slots() in a loop repeatedly, and the loop is not left until the request held in the slot completes. Ages ago, we used to use the slot->in_use member to get out of the loop, which misbehaved when the request in "slot" completes (at which time, the result of the request is copied away from the slot, and the in_use member is cleared, making the slot ready to be reused), and the "slot" gets reused to service a different request (at which time, the "slot" becomes in_use again, even though it is for a different request). The loop terminating condition mistakenly thought that the original request has yet to be completed. Today's code, after baa7b67d (HTTP slot reuse fixes, 2006-03-10) fixed this issue, uses a separate "slot->finished" member that is set in run_active_slot() to point to an on-stack variable, and the code that completes the request in finish_active_slot() clears the on-stack variable via the pointer to signal that the particular request held by the slot has completed. It also clears the in_use member (as before that fix), so that the slot itself can safely be reused for an unrelated request. One thing that is not quite clean in this arrangement is that, unless the slot gets reused, at which point the finished member is reset to NULL, the member keeps the value of &finished, which becomes a dangling pointer into the stack when run_active_slot() returns. Clear the finished member before the control leaves the function, which has a side effect of unconfusing compilers like recent GCC 12 that is over-eager to warn against such an assignment. Signed-off-by: Junio C Hamano <gitster@pobox.com>

Junio C Hamano committed Mar 2, 2023 at 08:44 UTC 5843080c85ae9d13f77442bec7bbec8e84a18100
1 file changed +26
http.c
+26
@@ -1523,6 +1523,32 @@ void run_active_slot(struct active_request_slot *slot)
1523 finish_active_slot(slot);
1524 }
1525 #endif
1526 +
1527 + /*
1528 + * The value of slot->finished we set before the loop was used
1529 + * to set our "finished" variable when our request completed.
1530 + *
1531 + * 1. The slot may not have been reused for another requst
1532 + * yet, in which case it still has &finished.
1533 + *
1534 + * 2. The slot may already be in-use to serve another request,
1535 + * which can further be divided into two cases:
1536 + *
1537 + * (a) If call run_active_slot() hasn't been called for that
1538 + * other request, slot->finished would have been cleared
1539 + * by get_active_slot() and has NULL.
1540 + *
1541 + * (b) If the request did call run_active_slot(), then the
1542 + * call would have updated slot->finished at the beginning
1543 + * of this function, and with the clearing of the member
1544 + * below, we would find that slot->finished is now NULL.
1545 + *
1546 + * In all cases, slot->finished has no useful information to
1547 + * anybody at this point. Some compilers warn us for
1548 + * attempting to smuggle a pointer that is about to become
1549 + * invalid, i.e. &finished. We clear it here to assure them.
1550 + */
1551 + slot->finished = NULL;
1552 }
1553
1554 static void release_active_slot(struct active_request_slot *slot)