-
Notifications
You must be signed in to change notification settings - Fork 32
refactor: EventLoop locking cleanups + client disconnect exception #160
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 1 commit
Commits
Show all changes
13 commits
Select commit
Hold shift + click to select a range
5108445
test: Add test coverage for client & server disconnections
ryanofsky f58c8d8
proxy-io.h: Add more detailed EventLoop comment
ryanofsky 9aaeec3
proxy-io.h: Add EventLoopRef RAII class handle addClient/removeClient…
ryanofsky 315ff53
refactor: Add ProxyContext EventLoop* member
ryanofsky 2b830e5
refactor: Use EventLoopRef instead of addClient/removeClient
ryanofsky f248947
refactor: Drop addClient/removeClient methods
ryanofsky 52256e7
refactor: Remove DestructorCatcher and AsyncCallable
vasild 9b8ed3d
refactor: Add clang thread safety annotations to EventLoop
ryanofsky 56fff76
Improve IPC client disconnected exceptions
ryanofsky 616d9a7
doc: Document ProxyClientBase destroy_connection option
ryanofsky ea38392
Prevent EventLoop async cleanup thread early exit during shutdown
ryanofsky 949573d
Prevent IPC server crash if disconnected during IPC call
ryanofsky 84cf56a
test: Test disconnects during IPC calls
ryanofsky File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As far as I can tell it is correct to not copy over the lock from the moved object here as long as the moved object has no lock. Should that be asserted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re: #160 (comment)
In commit "proxy-io.h: Add EventLoopRef RAII class handle addClient/removeClient refcounting" (9aaeec3)
It's kind of a corner case, and I think either behavior could be useful here. The point of this constructor is to be able to efficiently move a reference count from one owner to another would pointlessly incrementing & decrement the count when creating one reference and dropping the other.
I feel like it probably would not be useful to copy the
m_lock
pointer when doing that because practical effect of copying would be to make the new EventLoopRef object destructor skip locking when it is destroyed (it would assert m_lock is locked instead).On the other hand the default move-constructor would copy the m_lock value so maybe it is less surprising to follow the default behavior. And if the caller really wanted
m_lock
to be null after moving they could set it to null themselves.So this is a good catch and I think I'd now lean towards adding
m_lock{other.m_lock}
but I don't think the difference should matter in practice.More broadly I was also thinking about whether I could split EventLoopRef into a superclass without an
m_lock
member and a subclass with one to be able to get rid of therelock
option added in ea38392 which requires turning off thread safety analysis in the reset function. At the moment this class seems good at preventing reference counting bugs because it guarantees reference counts will always be decremented if they are incremented, but it doesn't have very easy to understand locking semantics so that's probably an area for improvement.