Fix WebSocket

[TienHuyIoT]

• Handle client disconnection event properly even if cleanupClients is not called within the main loop.
• Avoid self-deadlock by using recursive mutex.

[Copilot]

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

Comments suppressed due to low confidence (2)

src/AsyncWebSocket.cpp:877

• Modifications to the _clients vector in _handleDisconnect are not protected by any mutex. Ensure thread safety by protecting access to _clients if concurrent modifications may occur.

void AsyncWebSocket::_handleDisconnect(AsyncWebSocketClient *client) {

src/AsyncWebSocket.cpp:371

• The manual unlocking of the unique_lock before calling _client->close(true) could be error-prone if future changes introduce exceptions between the unlock and the following code. Consider refactoring the unlock logic into a dedicated scope or helper function to ensure exception safety.

lock.unlock();

[mathieucarbou]

@TienHuyIoT : if ESPAsyncWS cleans up itself, the current cleanup() method could be emptied (but only keep the signature with an empty body) and we can add a deprecation notice.

[TienHuyIoT]

if ESPAsyncWS cleans up itself, the current cleanup() method could be emptied (but only keep the signature with an empty body) and we can add a deprecation notice.

The cleanupClients() function has a maxClients argument, so I believe the cleanup() method should be used to handle situations where the number of connected clients exceeds the maxClients limit. However, its usage ultimately depends on the specific requirements of the user’s application.

[mathieucarbou]

cleanupClients

you are right! I forgot about this part.
thanks!

[mathieucarbou]

@vortigont @me-no-dev : care to have a look please ?

[mathieucarbou]

Tested, works fine.
Thanks for the improvement!

[vortigont]

looks nice! thanks!