In case you want to destruct the session asynchrounously, you can request a session +destruction proxy. If you don't do this, the destructor of the session object will +block while the trackers are contacted. If you keep one session_proxy to the +session when destructing it, the destructor will not block, but start to close down +the session, the destructor of the proxy will then synchronize the threads. So, the +destruction of the session is performed from the session destructor call until the +session_proxy destructor call. The session_proxy does not have any operations +on it (since the session is being closed down, no operations are allowed on it). The +only valid operation is calling the destructor:
+
+class session_proxy { ~session_proxy() };
+
+