-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Merge internal changes #915
Merged
sameb
merged 3 commits into
master
from
moe_writing_branch_from_156c8cc762fab971efb727c7ab107fa243be2fc9
Apr 21, 2015
Merged
Merge internal changes #915
sameb
merged 3 commits into
master
from
moe_writing_branch_from_156c8cc762fab971efb727c7ab107fa243be2fc9
Apr 21, 2015
Conversation
This file contains 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
FYI the dagger interop maven stuff is breaking due to the dagger 2.0 release. @cgruber is going to fix. |
------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=89998087
Now when you can create two independent singletons using the same injector in different threads. This make it easy to create scopes creating singletons using thread pools with all the concurrency being done by Guice. As a nice side effect Singleton scope is no longer treated specially in Guice codebase. The obvious problem to solve is potential deadlocks: A requires B, B requires C, C requires A where all are singletons and all are created simultaneously. It's impossible to detect this deadlock using information within one thread, so we have to have a shared storage. An idea is to have a map of creators' locks and a map of which threads are waiting for other singletons to be created. Using this information circular dependencies are trivially discovered within O(N) where N is a number of concurrent threads. Important to not that no other deadlock scenarios within Guice code is introduced as Guice does not expose any other scopes that can span several threads. Now it would be possible for client code to deadlock on itself with two lazy singletons calling each other's providers during creation. This is deemed as a non-issue as it is up to the client to write a thread-safe code. ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=91610630
…date api jar for the ant build) ------------- Created by MOE: http://code.google.com/p/moe-java MOE_MIGRATED_REVID=91679331
6986d18
to
3809a81
Compare
OK this is all set now. |
LGTM |
sameb
added a commit
that referenced
this pull request
Apr 21, 2015
…2fab971efb727c7ab107fa243be2fc9 Merge internal changes
This was referenced Jun 10, 2022
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.
Notably, this changes the singleton scope to get rid of the injector-wide lock.