-
Notifications
You must be signed in to change notification settings - Fork 12
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
Make the entire API thread-safe. #433
Conversation
There is not much point in trying to update it with the result of resolution.
This allows to have a single field, which can be `memoized` in the usual way. This will also become more important to make it thread-safe afterwards.
Somehow this was missed when introducing `memoized`.
Instead of storing them out-of-band in `PackageLoadingInfo`.
Instead of keeping them in a `PackageSymbol`-indexed map within the `Loader`. This gives the responsibility of handling the `PacakgeLoadingInfo` directly to the `PackageSymbol`, which therefore does not need to interact with the `Loader` itself anymore.
Rather than a global one for the whole context.
|
||
type DefiningTreeType = Nothing | ||
type DeclType = Symbol | ||
|
||
private[Symbols] val specialKind: SpecialKind = computeSpecialKind(name, owner) | ||
|
||
/** Package loading info with raw data from the classpath. */ | ||
private var optLoadingInfo: Option[PackageLoadingInfo] = None |
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.
just checking why this is safe to be a plain var?
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.
im assuming that the flow is that it is the thread that initialised the context is the thread that both creates this object and sets this, but then when is the update of setting this field "published" to other threads
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.
Hum, good question. For the members of other Symbol
s, they should be published thanks to myDeclarations.compareAndSet
at their PackageSymbol
's level. But for the things initialized during context initialization, we don't have a definitive release barrier. We might need to add one at the end of Context.initialize
perhaps?
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.
could be good
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.
Done.
On the condition that the `ClasspathEntry`s used to create the `Context` are thread-safe.
On the condition that the
ClasspathEntry
s used to create theContext
are thread-safe.