ChilePiquinandClaude Sonnet 5
f5f6fbe69a
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>
LanceDB Python SDK
A Python library for LanceDB.
Installation
pip install lancedb
Pre-Haswell x86_64 hosts: lancedb-compat
The default lancedb wheel targets x86-64-haswell (AVX2 + FMA + F16C) for full performance on modern hardware. Pre-Haswell hosts — Intel Sandy Bridge / Ivy Bridge / Westmere; AMD Bulldozer / Piledriver / Steamroller — don't have AVX2 and crash with Illegal instruction at import lancedb.
For those hosts, install the lancedb-compat package instead:
pip install lancedb-compat
Same Python API (import lancedb works as usual). The compat wheel is compiled at the x86-64-v2 baseline (Nehalem-class) and uses runtime SIMD dispatch in the embedded lance crate to pick the right kernel tier (scalar / AVX / AVX+FMA / AVX2+FMA / AVX-512) at load time, so it still goes fast on modern hardware while running cleanly on the pre-Haswell silicon. Use lance.simd_info() from Python to verify which tier was selected.
lancedb and lancedb-compat install to the same lancedb/ namespace and conflict at install time. Pick one. To switch, pip uninstall lancedb first, then pip install lancedb-compat (or vice-versa).
If you need a custom baseline (or lancedb-compat isn't yet published for your platform), build from source with the override:
RUSTFLAGS="-C target-cpu=x86-64-v2" maturin build --release
pip install ./target/wheels/lancedb-*.whl
Preview Releases
Stable releases are created about every 2 weeks. For the latest features and bug fixes, you can install the preview release. These releases receive the same level of testing as stable releases, but are not guaranteed to be available for more than 6 months after they are released. Once your application is stable, we recommend switching to stable releases.
pip install --pre --extra-index-url https://pypi.fury.io/lancedb/ lancedb
Threading in CPU-limited containers
LanceDB uses separate pools for compute work and storage I/O. On a container with two visible CPUs, current releases intentionally use one compute worker by default; no manual configuration is needed. If every query logs an I/O core reservation warning on a two-CPU container, upgrade from LanceDB 0.21.1 or earlier.
The two commonly tuned environment variables control different resources:
LANCE_CPU_THREADSoverrides the number of compute workers. One worker is the appropriate setting for a two-CPU container when an explicit override is needed.LANCE_IO_THREADScontrols concurrent storage operations, not reserved CPU cores. Its default can be greater than the number of CPUs because I/O workers spend much of their time waiting for storage.
Keep the defaults unless measurements show that the workload benefits from an override. See the Lance threading model for the current defaults and tuning guidance.
Usage
Basic Example
import lancedb
db = lancedb.connect('<PATH_TO_LANCEDB_DATASET>')
table = db.open_table('my_table')
results = table.search([0.1, 0.3]).limit(20).to_list()
print(results)
Development
See CONTRIBUTING.md for information on how to contribute to LanceDB.