Skip to content
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

Merged
merged 12 commits into from
Jan 13, 2024
Merged

Conversation

sjrd
Copy link
Contributor

@sjrd sjrd commented Dec 22, 2023

On the condition that the ClasspathEntrys used to create the Context are thread-safe.

sjrd added 11 commits December 21, 2023 11:14
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.
@sjrd sjrd requested review from adpi2 and bishabosha January 8, 2024 07:43

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
Copy link
Member

@bishabosha bishabosha Jan 9, 2024

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?

Copy link
Member

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

Copy link
Contributor Author

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 Symbols, 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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could be good

Copy link
Contributor Author

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.
@bishabosha bishabosha merged commit ce0fdb4 into scalacenter:main Jan 13, 2024
4 checks passed
@sjrd sjrd deleted the thread-safe branch January 13, 2024 22:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants