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 has been 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_callbacks
is called, one of which is fromclient::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.
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 iftry_commit
is called on a disconnected client and it throws an exception.The documentation of
client::disconnect
should 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:
The text was updated successfully, but these errors were encountered: