Tacopie TCP server library (read access violation after close under TCP zero window condition) about tacopie HOT 4 OPEN

Hi Edwin,

Thanks for reaching out to me and for the detailed explanation!

Technically, when the tcp_client is destroyed, it will call .disconnect(true) internally.
Note that we pass true as a parameter, which enables the option wait_for_removal.
This option blocks the thread until all pending callbacks are processed.

Considering your case, it seems that this waiting process does not occur.
In such case, when going through the code of the tcp_client, the only possibility would be:
disconnect() is called after a read or a write failure. In such case, wait_for_removal is not set to true, which means the function returns right away.
when the tcp_client is destroyed, the destructor is called, leading to disconnect to be called. But because the client is already marked as disconnected, the function returns right away.
This would match your current context where the client fails to read from the remote server.
Even though the .disconnect prevents the insertion of new write requests and clear the write requests, it is indeed true that there may be a thread notifying the tcp_client about a write event on the socket because we started to watch before the disconnection.

However, the fix is not as trivial as it may sound:
Calling disconnect(true) from the read or write callback will block indefinitely: it would wait for the callbacks to be executed, but the callback is waiting for itself to complete
Always waiting for callback cleanup in the destructor can also be an issue: if the client is disconnected, and the socket closed as it is right now, the socket file descriptor might be reused by the operating system when initiating a new socket. Then, when trying to wait for a cleanup, we will actually wait for the cleanup of another socket.
I guess the best solution at the moment would be:
Always check for callback cleanup when the destructor is called, even if the client has been marked as disconnected
Do not close the socket until the client is destroyed. That would avoid the operating system to reuse the same socket identifier.
I'm gonna have a fix and will try to release that ASAP, will keep you up to date :)

Best and thanks a lot for reporting that, really appreciate!