Repository navigation
Conversation
…eport false success Fix a group of related defects in the C client watch removal APIs: - In the multithreaded library, a local removal with zoo_aremove_watches() or zoo_aremove_all_watches() cast the caller's data pointer to a sync completion and signaled it. This wrote mutex state into application memory and could hang in pthread_mutex_lock. aremove_watches() no longer signals a sync completion. A local removal is complete when the call returns, so the synchronous wrapper waits only for removals that go to the server. A local removal does not call the completion, as before. The header now documents this. - zoo_aremove_watches() and zoo_aremove_all_watches() declared the completion as void_completion_t *, a pointer to a function pointer. Correct callers failed to compile in C++ and with GCC 14. Declare it as void_completion_t. The ABI does not change. - containsWatcher() matched a NULL watcher before it looked up the path. A local removal of all watches returned ZOK for a path with no watches. Return ZNOWATCHER, as the header documents and as the Java client does. Add the real-server test Zookeeper_simpleSystem::testAsyncRemoveWatchers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…oveWatchers testRemoveWatchers stops the server and does not start it again. It was the last test in Zookeeper_simpleSystem, so this did not matter before. testAsyncRemoveWatchers now runs after it and failed with ZCONNECTIONLOSS in the full suite. Start the server again at the end of testRemoveWatchers. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix a group of related defects in the C client watch removal APIs:
zoo_aremove_watches()orzoo_aremove_all_watches()cast the caller's data pointer to a sync completion and signaled it. This writes mutex state into application memory and can hang inpthread_mutex_lock. After the fixaremove_watches()no longer signals a sync completion. A local removal is complete when the call returns, so the synchronous wrapper waits only for removals that go to the server. A local removal does not call the completion, as before. The header documents these semantics.zoo_aremove_watches()andzoo_aremove_all_watches()declared the completion asvoid_completion_t *, a pointer to a function pointer. Correct callers failed to compile in C++ and with GCC 14. The fix declare its asvoid_completion_t. The ABI does not change.containsWatcher()matched aNULLwatcher before it looked up the path. A local removal of all watches returnedZOKfor a path with no watches. The fix is to returnZNOWATCHER, as the header mentions and as the Java client does.Adds the test
Zookeeper_simpleSystem::testAsyncRemoveWatchers.