Skip to content

RaBitQ Library 0.8.1

This patch release fixes a crash on macOS when RaBitQ Library runs in the same process as Faiss and PyTorch, reported through txtai (#207).

Fixes

  • num_threads=0, the default for train, add and clustering, now selects the available logical CPUs capped by the OpenMP thread limit (OMP_NUM_THREADS, or omp_set_num_threads in C++), as Faiss does. Positive requests are unchanged and remain capped only by the CPU count. Without OMP_NUM_THREADS, the default still uses every available CPU.
  • In 0.8.0, 0.7-style add(x) calls switched to every CPU and ignored OMP_NUM_THREADS. On macOS, the Faiss, PyTorch and RaBitQ Library wheels each bundle their own OpenMP runtime; with Faiss and PyTorch loaded, starting RaBitQ Library's worker threads crashed with OMP: Error #179 followed by a segmentation fault. Applications that set OMP_NUM_THREADS=1 for this reason, such as txtai, run add single-threaded again. Processes that mix these runtimes without that setting should set it before the first native call or pass num_threads=1; see threading.

Upgrading

From 0.8.0, public APIs, index file formats and the stable core API v1 are unchanged; no index conversion is required. If you set OMP_NUM_THREADS and want train or add to use more threads, pass num_threads explicitly. Rebuild C++ consumers with matching headers and libraries; no cross-version C++ binary ABI is promised.

When upgrading from 0.7, follow the 0.8.0 release notes and the migration guide.