You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Apr 6, 2019. It is now read-only.
There are several cases where client::clear_callbacks is called, one of which is from client::disconnect. clear_callbacks will copy a list of callbacks to execute on a detached thread and update the state of the callback condition variable through several member variables. There are a few issues that need to be addressed with this approach:
The client can be deleted while the detached thread is still running, which will cause access violations when the thread tries to modify member variables of a deleted instance.
It would be a good idea to block on the condition variable inside the destructor and wait for the callback count to reach 0, which will ensure that the zero or more outstanding detached threads have finished.
There is no user accessible function that can be used to wait for existing callback functions that are running in the background to finish. This can be important when using disconnect since it will start a detached thread to reject commands that haven't been sent. sync_commit comes close since the end of the function waits on the condition variable, but that will never happen if try_commit is called on a disconnected client and it throws an exception.
The documentation of client::disconnect should also be changed since it currently states
wait_for_removal when sets to true, disconnect blocks until the underlying TCP client has
been effectively removed from the io_service and that all the underlying callbacks have completed.
I'm assuming it's referring to internal I/O callbacks, but the wording makes it seem like it will block until command callbacks have been completed.
This is a Windows example that can be used to reproduce the access violation on delete:
There are several cases where
client::clear_callbacksis called, one of which is fromclient::disconnect.clear_callbackswill copy a list of callbacks to execute on a detached thread and update the state of the callback condition variable through several member variables. There are a few issues that need to be addressed with this approach:The client can be deleted while the detached thread is still running, which will cause access violations when the thread tries to modify member variables of a deleted instance.
There is no user accessible function that can be used to wait for existing callback functions that are running in the background to finish. This can be important when using
disconnectsince it will start a detached thread to reject commands that haven't been sent.sync_commitcomes close since the end of the function waits on the condition variable, but that will never happen iftry_commitis called on a disconnected client and it throws an exception.The documentation of
client::disconnectshould also be changed since it currently statesI'm assuming it's referring to internal I/O callbacks, but the wording makes it seem like it will block until command callbacks have been completed.
This is a Windows example that can be used to reproduce the access violation on delete: