Skip to content

Conversation

@gatesn
Copy link
Contributor

@gatesn gatesn commented Sep 13, 2025

This fixes a problem where we can spawn a task that holds onto handle (since it has a static lifetime, ergh) can keep a runtime alive even after the caller drops it. For futures that use channels, e.g. the FileRead I/O, this results in read futures that hang forever when the runtime is dropped (because the executor holds the pending recv end of the channel, and the executor is kept alive by the send end of the channel...)

We also impl BlockingRuntime for CurrentThreadRuntime as this will likely become the default runtime for language bindings to use.

Signed-off-by: Nicholas Gates <nick@nickgates.com>
Signed-off-by: Nicholas Gates <nick@nickgates.com>
@gatesn gatesn added the changelog/fix A bug fix label Sep 13, 2025
@gatesn gatesn enabled auto-merge (squash) September 13, 2025 20:14
/// The future is provided a [`Handle`] to the runtime so that it may spawn additional tasks
/// to be executed concurrently.
fn block_on<Fut, R>(&self, f: Fut) -> R
fn block_on<F, Fut, R>(&self, f: F) -> R
Copy link
Contributor Author

Choose a reason for hiding this comment

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

We change the API to take a handle so it's harder to write code that drops the runtime too early.

It would be impossible to write code that drops the runtime too early if we could embed a lifetime in the handle. But alas. My week long dive into Rust revealed this is simply not possible :'(

@gatesn gatesn requested a review from AdamGS September 13, 2025 20:16
@gatesn gatesn changed the title Convert handles to hold weak reference to their runtime Convert handles to hold weak reference to their executor Sep 13, 2025
Signed-off-by: Nicholas Gates <nick@nickgates.com>
@codspeed-hq
Copy link

codspeed-hq bot commented Sep 13, 2025

CodSpeed Performance Report

Merging #4624 will not alter performance

Comparing ngates/weak-handle (ac952ac) with develop (07015ec)

Summary

✅ 1351 untouched

@codecov
Copy link

codecov bot commented Sep 13, 2025

Codecov Report

❌ Patch coverage is 91.98606% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.01%. Comparing base (07015ec) to head (ac952ac).
⚠️ Report is 1 commits behind head on develop.

Files with missing lines Patch % Lines
vortex-io/src/runtime/tokio.rs 80.95% 8 Missing ⚠️
vortex-io/src/runtime/current.rs 86.95% 6 Missing ⚠️
vortex-io/src/runtime/single.rs 58.33% 5 Missing ⚠️
vortex-file/src/writer.rs 33.33% 2 Missing ⚠️
vortex-io/src/runtime/handle.rs 88.88% 1 Missing ⚠️
vortex-io/src/runtime/smol.rs 66.66% 1 Missing ⚠️

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Signed-off-by: Nicholas Gates <nick@nickgates.com>
Copy link
Contributor

@robert3005 robert3005 left a comment

Choose a reason for hiding this comment

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

the statics inside functions are a bit weird style but they work

@gatesn gatesn merged commit 4bce0a3 into develop Sep 13, 2025
37 checks passed
@gatesn gatesn deleted the ngates/weak-handle branch September 13, 2025 23:07
gatesn added a commit that referenced this pull request Sep 15, 2025
This PR moves our I/O layer over from the old pre-fetching segment
source to the new coalescing File I/O implementation on the Vortex
runtime.

Note: this PR currently includes #4624 

## Breaking Changes

* `VortexOpenOptions` is no longer generic.
* Fix: find/replace `VortexOpenOptions::file` ->
`VortexOpenOptions::new`
* `VortexOpenOptions::in_memory().open(...)` is replaced by
`VortexOpenOptions::new().open_buffer(...)`

## Performance

Generally this PR is about even, or slightly improved. There is some
variance on some of the S3 benchmarks.

The big regressions are in DuckDB on S3, where our read path has a
custom work-stealing queue that doesn't buffer enough of the scan to
perform effective pre-fetching. DataFusion doesn't have this problem, so
we see much less of an impact.

I want to follow up to this PR to switch over DuckDB to avoid this
getting large, and accept the short-term regression.

---------

Signed-off-by: Nicholas Gates <nick@nickgates.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

changelog/fix A bug fix

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants