lithdew / snow Goto Github PK

Ideally, when Client.deinit() / Server.deinit() is called, all heap allocations associated to connections pooled in either should be freed before deinit() returns.

There are two strategies on how memory/resources are cleaned up after a single connection associated with a Client / Server right now:

1. When the socket underlying a connection is signaled to have been closed locally/by a peer, the connection would clean itself up and deallocate all of its resources.
2. When Client.deinit() / Server.deinit() is called, all live connections are manually closed and deallocated.

There is an edge case to consider with snow's current approach: after Client.deinit() / Server.deinit() is called which cleans up connections as denoted in Strategy 2, there may still exist connections or resources associated to said Client / Server cleaning themselves up via Strategy 1 for a brief moment.

The standard practice to ensure that once Client.deinit() / Server.deinit() returns, that all heap allocations associated to a Client / Server are de-allocated, is to keep a mutex-protected cleanup queue of dead connections whose resources have yet to be destroyed. When the socket underlying a connection is signalled to have been closed locally/by a peer, the connection would queue itself into said queue.

Periodically, i.e. after a socket is accepted on a Server, or after a connection is made on a Client, the mutex-protected cleanup queue of dead connections would be polled for dead connections. If there exist entries in said queue, empty out the queue and destroy all resources associated with the entries within the queue.

The downside to this approach is that this would require maintaining a separate queue solely for resource deallocation which must be periodically checked, alongside something akin to a sync.WaitGroup which waits until all existing frames driving connections have returned.

If a more optimal approach is found, I'll take on implementing the new approach.