ChilePiquinandClaude Sonnet 5 f5f6fbe69a fix(python): stop using Arc::strong_count to decide when the runtime is idle
Review on this PR found three more real bugs in the previous commit's
exit-lifecycle design, all traceable to the same root cause: using
Arc::strong_count as a proxy for "is anything still using the runtime"
is the wrong signal. It reflects who currently holds a reference, not
who's logically still in flight, and it let a spawned task become the
final, worker-thread-side owner of the Runtime -- which reproduced
unprompted in this branch's own test suite (a panic: "cannot drop a
runtime in a context where blocking is not allowed").

Specifically:

- A task holding an Arc for its own whole lifetime could end up being
  the one to drop the Runtime when it completes, which panics if that
  drop happens on one of the runtime's own worker threads.
- shutdown() bailed out as soon as it saw an empty slot, so an install
  already in progress at that exact moment could finish afterward,
  leaving a live, un-waited-for runtime behind as the interpreter moved
  on into teardown.
- Once the bounded wait elapsed, shutdown() simply returned without
  touching the runtime at all, recreating the original race for any
  call slower than the grace period.

Replaces Arc-based tracking with an explicit OUTSTANDING counter that
every top-level spawn/spawn_blocking/block_on call increments before it
starts and decrements only once it has truly finished, via an
OutstandingGuard token that carries no reference to the runtime itself.
shutdown() waits for this to reach zero (not for Arc::strong_count to
look low) before ever touching the runtime, and forces the retirement
attempt anyway once its bound elapses instead of leaving the runtime
untouched.

Also narrows what the fork-child handler is allowed to do. ArcSwapOption
turned out not to be safe to call from there either: swap/compare_and_swap
reconcile reader "debts" internally (thread-local state, potentially an
allocation), none of which is safe in a forked child that may have
inherited another thread's lock mid-acquisition. The handler now only
bumps a bare GENERATION counter; get_runtime() compares its installed
runtime's generation against the live counter from ordinary (non-signal)
context and rebuilds on a mismatch, exactly the check the handler used
to perform directly.

Verified against the same concurrent reproducer as the previous commit:
50/50 clean runs (vs. hangs and, separately, an unprompted panic under
the prior design), plus a 30-second-join variant and a targeted test
forcing the install-vs-shutdown race directly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-15 06:51:39 -06:00
2026-09-09 15:33:04 +08:00
2023-03-17 18:15:19 -07:00
2025-03-10 09:01:23 -07:00

LanceDB Cloud Public Beta

LanceDB Website Blog Discord Twitter LinkedIn

LanceDB

The Multimodal AI Lakehouse

How to Install ✦ Detailed Documentation ✦ Tutorials and Recipes ✦ Contributors

The ultimate multimodal data platform for AI/ML applications.

LanceDB is designed for fast, scalable, and production-ready vector search. It is built on top of the Lance columnar format. You can store, index, and search over petabytes of multimodal data and vectors with ease. LanceDB is a central location where developers can build, train and analyze their AI workloads.


Demo: Multimodal Search by Keyword, Vector or with SQL

LanceDB Multimodal Search

Star LanceDB to get updates!

⭐ Click here ⭐ to see how fast we're growing!

Key Features:

  • Fast Vector Search: Search billions of vectors in milliseconds with state-of-the-art indexing.
  • Comprehensive Search: Support for vector similarity search, full-text search and SQL.
  • Multimodal Support: Store, query and filter vectors, metadata and multimodal data (text, images, videos, point clouds, and more).
  • Advanced Features: Zero-copy, automatic versioning, manage versions of your data without needing extra infrastructure. GPU support in building vector index.

Products:

  • Open Source & Local: 100% open source, runs locally or in your cloud. No vendor lock-in.
  • Cloud and Enterprise: Production-scale vector search with no servers to manage. Complete data sovereignty and security.

Ecosystem:

  • Columnar Storage: Built on the Lance columnar format for efficient storage and analytics.
  • Seamless Integration: Python, Node.js, Rust, and REST APIs for easy integration. Native Python and Javascript/Typescript support.
  • Rich Ecosystem: Integrations with LangChain 🦜️🔗, LlamaIndex 🦙, Apache-Arrow, Pandas, Polars, DuckDB and more on the way.

How to Install:

Follow the Quickstart doc to set up LanceDB locally.

API & SDK: We also support Python, Typescript and Rust SDKs

Interface Documentation
Python SDK https://lancedb.github.io/lancedb/python/python/
Typescript SDK https://lancedb.github.io/lancedb/js/globals/
Rust SDK https://docs.rs/lancedb/latest/lancedb/index.html
REST API https://docs.lancedb.com/api-reference/rest

Join Us and Contribute

We welcome contributions from everyone! Whether you're a developer, researcher, or just someone who wants to help out.

If you have any suggestions or feature requests, please feel free to open an issue on GitHub or discuss it on our Discord server.

Check out the GitHub Issues if you would like to work on the features that are planned for the future. If you have any suggestions or feature requests, please feel free to open an issue on GitHub.

Contributors

Stay in Touch With Us


Website Blog Discord Twitter LinkedIn

S
Description
Developer-friendly OSS embedded retrieval library for multimodal AI. Search More; Manage Less.
Readme Apache-2.0
137 MiB
Languages
Rust 46%
Python 28.3%
HTML 17.7%
TypeScript 7.2%
Java 0.6%
Other 0.1%