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

Enforce and await cleanup in StarlarkBaseExternalContext #22772

Closed
wants to merge 4 commits into from

Conversation

fmeum
Copy link
Collaborator

@fmeum fmeum commented Jun 17, 2024

StarlarkBaseExternalContext now implements AutoCloseable and, in close():

  1. Cancels all pending async tasks.
  2. Awaits their termination.
  3. Cleans up the working directory (always for module extensions, on failure for repo rules).
  4. Fails if there were pending async tasks in an otherwise successful evaluation.

Previously, module extensions didn't do any of those. Repo rules did 1 and 4 and sometimes 3, but not in all cases.

This change required replacing the fixed-size thread pool in DownloadManager with virtual threads, thereby resolving a TODO about not using a fixed-size thread pool for the GrpcRemoteDownloader.

Work towards #22680
Work towards #22748

@github-actions github-actions bot added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. awaiting-review PR is awaiting review from an assigned reviewer labels Jun 17, 2024
@meteorcloudy
Copy link
Member

OK, I'll delegate this one to @Wyverald 😃

Copy link
Member

@Wyverald Wyverald left a comment

Choose a reason for hiding this comment

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

this is really nice! thank you!

Copy link
Member

Choose a reason for hiding this comment

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

just a general comment, no immediate AIs: this class is looking less and less like a DownloadManager now, especially as there's no central thread pool anymore. It's really just a more sophisticated Downloader that takes care of some things like URL rewriting, credential helpers, etc.

@fmeum fmeum force-pushed the wait-for-executor-shutdown branch from b851487 to 86acedb Compare June 18, 2024 06:16
@fmeum fmeum requested a review from Wyverald June 18, 2024 06:17
@fmeum
Copy link
Collaborator Author

fmeum commented Jun 18, 2024

@bazel-io fork 7.2.1

@fmeum
Copy link
Collaborator Author

fmeum commented Jun 18, 2024

@bazel-io fork 7.3.0

@Wyverald Wyverald added awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally and removed awaiting-review PR is awaiting review from an assigned reviewer labels Jun 18, 2024
@github-actions github-actions bot removed the awaiting-PR-merge PR has been approved by a reviewer and is ready to be merge internally label Jun 19, 2024
@fmeum fmeum deleted the wait-for-executor-shutdown branch June 20, 2024 07:26
fmeum added a commit to fmeum/bazel that referenced this pull request Jun 20, 2024
`StarlarkBaseExternalContext` now implements `AutoCloseable` and, in `close()`:
1. Cancels all pending async tasks.
2. Awaits their termination.
3. Cleans up the working directory (always for module extensions, on failure for repo rules).
4. Fails if there were pending async tasks in an otherwise successful evaluation.

Previously, module extensions didn't do any of those. Repo rules did 1 and 4 and sometimes 3, but not in all cases.

This change required replacing the fixed-size thread pool in `DownloadManager` with virtual threads, thereby resolving a TODO about not using a fixed-size thread pool for the `GrpcRemoteDownloader`.

Work towards bazelbuild#22680
Work towards bazelbuild#22748

Closes bazelbuild#22772.

PiperOrigin-RevId: 644669599
Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624
github-merge-queue bot pushed a commit that referenced this pull request Jun 20, 2024
…22814)

`StarlarkBaseExternalContext` now implements `AutoCloseable` and, in
`close()`:
1. Cancels all pending async tasks.
2. Awaits their termination.
3. Cleans up the working directory (always for module extensions, on
failure for repo rules).
4. Fails if there were pending async tasks in an otherwise successful
evaluation.

Previously, module extensions didn't do any of those. Repo rules did 1
and 4 and sometimes 3, but not in all cases.

This change required replacing the fixed-size thread pool in
`DownloadManager` with virtual threads, thereby resolving a TODO about
not using a fixed-size thread pool for the `GrpcRemoteDownloader`.

Work towards #22680
Work towards #22748

Closes #22772

PiperOrigin-RevId: 644669599
Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624

Closes #22775
@iancha1992
Copy link
Member

The changes in this PR have been included in Bazel 7.2.1 RC2. Please test out the release candidate and report any issues as soon as possible.
If you're using Bazelisk, you can point to the latest RC by setting USE_BAZEL_VERSION=7.2.1rc2. Thanks!

fmeum added a commit to fmeum/bazel that referenced this pull request Jun 25, 2024
`StarlarkBaseExternalContext` now implements `AutoCloseable` and, in `close()`:
1. Cancels all pending async tasks.
2. Awaits their termination.
3. Cleans up the working directory (always for module extensions, on failure for repo rules).
4. Fails if there were pending async tasks in an otherwise successful evaluation.

Previously, module extensions didn't do any of those. Repo rules did 1 and 4 and sometimes 3, but not in all cases.

This change required replacing the fixed-size thread pool in `DownloadManager` with virtual threads, thereby resolving a TODO about not using a fixed-size thread pool for the `GrpcRemoteDownloader`.

Work towards bazelbuild#22680
Work towards bazelbuild#22748

Closes bazelbuild#22772.

PiperOrigin-RevId: 644669599
Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624
github-merge-queue bot pushed a commit that referenced this pull request Jun 25, 2024
…22883)

`StarlarkBaseExternalContext` now implements `AutoCloseable` and, in
`close()`:
1. Cancels all pending async tasks.
2. Awaits their termination.
3. Cleans up the working directory (always for module extensions, on
failure for repo rules).
4. Fails if there were pending async tasks in an otherwise successful
evaluation.

Previously, module extensions didn't do any of those. Repo rules did 1
and 4 and sometimes 3, but not in all cases.

This change required replacing the fixed-size thread pool in
`DownloadManager` with virtual threads, thereby resolving a TODO about
not using a fixed-size thread pool for the `GrpcRemoteDownloader`.

Work towards #22680
Work towards #22748

Closes #22772.

PiperOrigin-RevId: 644669599
Change-Id: Ib71e5bf346830b92277ac2bd473e11c834cb2624

Closes #22776
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants