The closed slot system was a solution to manage the possiblity that a pcb might have been closed by LwIP while operations were still pending on the async thread. When doing load testing on an ESP32-S2 last year, I discovered a possible race condition with this code:

• the async thread attempts a LwIP call on an AsyncClient such as _tcp_recved, copying the tcp_pcb* and closed_slot index in to a tcpip_api_call_data structure, then blocking in tcpip_api_call waiting for the LwIP thread.
• Next, the LwIP thread processes an incoming packet for that connection, but cannot allocate a pbuf (or has some other issue); it calls tcp_error, unbinding the closed_slot, queuing the error event for the AsyncClient, and disposing of the tcp_pcb*. This frees some memory.
• The LwIP thread then processes a new connection, calls tcp_accept, ultimately re-assigning the closed_slot to a new tcp_pcb*.
• Finally, with no more inbound packets to process, the LwIP thread services the tcpip_api_call, which finds that the closed_slot is valid -- and attempts to write through the discarded tcp_pcb*.
• Kaboom!

It turns out that the underlying problem that closed_slots was invented to solve admits a simpler solution. Since only the LwIP thread can invalidate a tcp_pcb* (either by notifiying us it's doing so via tcp_error, or by client calls to tcp_close or tcp_abort), we can treat AsyncClient::_pcb as "owned" under the LwIP mutex. Instead of the tcp_api_call_t storing the handle directly, we can instead pass a pointer to AsyncClient::_pcb; and arrange that any invalidation operation sets it to null while the mutex is still held. This permits us to safely check for validity inside the _tcp_x_api calls, as they also hold the mutex. Essentially, instead of managing separate life cycle tracking storage, we leverage the memory in AsyncClient itself to keep a safe view whenever any operation takes place in the LwIP context.