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

Fix #2024: Use a shared Scope in the sbt plugin for all parallel tasks #2039

Merged

Conversation

WojciechMazur
Copy link
Contributor

@WojciechMazur WojciechMazur commented Nov 27, 2020

This PR resolves #2024
When creating JarDirectory it creates a new FileSystem with URI based on jar path. It's acquired into Scope, registered global filesystems register, and closed after exiting it. In normal conditions when we're building only a single App it does not yield any problems. However, when there are multiple modules linked into executables in parallel exiting Scope may close FileSystem that is still used in other threads. It may result in ClosedFileSystemException

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 of Scope to AtomicReference instead of var

@sjrd
Copy link
Collaborator

sjrd commented Nov 29, 2020

Shouldn't we instead pass down a more appropriate Scope, which would be shared by parallel linking operations? Not closing the file systems can leave the .jar's locked, which can cause issues for projects with exportJars for example.

We can use sbt's onComplete as a hook of when to appropriate close down a Scope shared by concurrent tasks.

@WojciechMazur WojciechMazur changed the title Do not acquire shared JarDirectory FileSystem Use shared scope in build Nov 30, 2020
@WojciechMazur
Copy link
Contributor Author

@sjrd I've changed the implementation to use shared scope instead as you hinted.

@sjrd sjrd changed the title Use shared scope in build Fix #2024: Use a shared Scope in the sbt plugin for all parallel tasks Nov 30, 2020
@sjrd sjrd merged commit 2e5581e into scala-native:master Nov 30, 2020
@WojciechMazur WojciechMazur deleted the fix/dont_acquire_jar_filesystem branch February 15, 2021 09:08
ekrich pushed a commit to ekrich/scala-native that referenced this pull request May 21, 2021
…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.
WojciechMazur added a commit to WojciechMazur/scala-native that referenced this pull request Aug 25, 2021
…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.
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.

nativeLink is flaky with (error: java.nio.file.ClosedFileSystemException)
2 participants