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
Fix #2024: Use a shared Scope in the sbt plugin for all parallel tasks #2039
Fix #2024: Use a shared Scope in the sbt plugin for all parallel tasks #2039
Conversation
Shouldn't we instead pass down a more appropriate We can use sbt's |
32e9fb9
to
b000154
Compare
@sjrd I've changed the implementation to use shared scope instead as you hinted. |
util/src/main/scala/scala/scalanative/util/SharedScopeProvider.scala
Outdated
Show resolved
Hide resolved
sbt-scala-native/src/main/scala/scala/scalanative/sbtplugin/ScalaNativePluginInternal.scala
Outdated
Show resolved
Hide resolved
sbt-scala-native/src/main/scala/scala/scalanative/sbtplugin/ScalaNativePluginInternal.scala
Show resolved
Hide resolved
…arallel tasks (scala-native#2039) When creating a `JarDirectory`, it creates a new `FileSystem` with a URI based on the jar path. It is acquired by the enclosing `Scope`, and closed after that scope is closed. When building a single application, it does not yield any problem. However, when there are multiple modules linked into executables in parallel, exiting one of the `Scope`s may close a `FileSystem´ that is still used in other threads. It may result in a `ClosedFileSystemException`. This commit introduces a shared Scope used by tasks running as part of the same command, and closed in sbt's `onComplete` event. We also change the implementation of `Scope` to use an `AtomicReference` instead of a `var`, so that `Scope` itself becomes thread-safe.
…arallel tasks (scala-native#2039) When creating a `JarDirectory`, it creates a new `FileSystem` with a URI based on the jar path. It is acquired by the enclosing `Scope`, and closed after that scope is closed. When building a single application, it does not yield any problem. However, when there are multiple modules linked into executables in parallel, exiting one of the `Scope`s may close a `FileSystem´ that is still used in other threads. It may result in a `ClosedFileSystemException`. This commit introduces a shared Scope used by tasks running as part of the same command, and closed in sbt's `onComplete` event. We also change the implementation of `Scope` to use an `AtomicReference` instead of a `var`, so that `Scope` itself becomes thread-safe.
This PR resolves #2024
When creating
JarDirectory
it creates a newFileSystem
with URI based on jar path. It's acquired intoScope
, registered global filesystems register, and closed after exiting it. In normal conditions when we're building only a singleApp
it does not yield any problems. However, when there are multiple modules linked into executables in parallel exitingScope
may close FileSystem that is still used in other threads. It may result inClosedFileSystemException
This PR removes acquiring the mentioned FieleSystem. It means also means it would not be closed as before.JarDirectory currently is the only place using
Scope
, so we may try to remove it entirely from the codebase.This PR introduces shared scope used in multiple builds and closed on
onComplete
sbt event. It also changes implementation ofScope
toAtomicReference
instead ofvar