repository·main·Indexed 21 days ago
https://github.com/xbbg-org/xbbgA high-performance Bloomberg client powered by a shared Rust engine with interfaces for Python, Node.js, and .NET. It provides tools for retrieving reference data (bdp), historical data (bdh), bulk data (bds), and intraday bars (bdib), supporting modern data formats like Arrow, Polars, and DuckDB. The ecosystem includes xbbg-cli for command-line retrieval and xbbg-mcp, an MCP server for integrating Bloomberg workflows into AI tools like Claude Code and OpenCode.
dotnet-xbbg provides C#/.NET bindings for the xbbg Bloomberg engine. It uses csbindgen to bridge the pure Rust engine (xbbg-core and xbbg-async) to the .NET ecosystem. The architecture follows a layered approach: the Rust engine provides the core logic, dotnet-xbbg provides C-ABI exports, and the XbbgSharp.dll NuGet package provides idiomatic C# wrappers for developers.blpapi-sys provides unsafe, zero-policy FFI bindings to Bloomberg's C API (blpapi_*). These bindings are auto-generated at build time using bindgen from the Bloomberg SDK headers.
Key characteristics:
#![no_std]: It has no runtime dependencies beyond the Bloomberg SDK.unsafe and follow the C ABI. Types are not marked Send or Sync unless explicitly guaranteed by the C SDK.xbbg-sys is an FFI (Foreign Function Interface) abstraction layer that re-exports blpapi-sys. It serves as the single FFI import boundary for the xbbg workspace, providing access to the Bloomberg SDK C bindings.
Important Safety Note: All APIs provided by this crate are unsafe C FFI calls. End-users should generally use xbbg-core instead, as it provides safe Rust abstractions over these low-level bindings.
xbbg-core provides safe, zero-allocation Rust wrappers over the Bloomberg C++ SDK (blpapi). It serves as the core abstraction layer between the raw FFI (xbbg-sys) and the async engine (xbbg-async). The crate ensures that every unsafe FFI call is wrapped in a safe Rust API with proper ownership, lifetimes, and error handling.xbbg-core and xbbg-async), which is then exposed to JavaScript via the js-xbbg npm package and TypeScript definitions.pyo3-xbbg crate provides Python bindings for the xbbg Bloomberg engine using PyO3. It exposes the underlying Rust engine to Python through the xbbg._core module. This allows Python developers to leverage the high-performance Rust implementation of the xbbg engine directly within their Python environments.The @xbbg/core package provides high-performance Bloomberg data access with the following characteristics:
apache-arrow for efficient data handling.xbbg-async is an asynchronous worker-pool engine built on top of xbbg-core designed to handle Bloomberg API requests and subscriptions.
To avoid contention and handle the fact that Bloomberg's Session is not Sync, the engine uses a thread-per-session model. Instead of sharing a single session via a Mutex, the architecture splits work into two distinct pools:
Session and manages request lifecycles using one of 12 specialized state machines (e.g., RefData, HistData, Bql, IntradayBar).Additionally, the engine utilizes a SchemaCache (in-memory and disk-persisted) and a FieldCache (global and disk-persisted) to optimize service schema introspection and field type resolution.
The crate is organized into several functional areas that manage the lifecycle of Bloomberg data interaction:
element.rs: Element wrapper for typed field access and iteration.message.rs: Message wrapper providing correlation IDs and topic names.event.rs: Event and MessageIterator for handling incoming data streams.name.rs: Name interning using an FxHashMap cache.value.rs: A dynamic Value enum used instead of JSON serialization for performance.datatype.rs: DataType enum mapping Bloomberg type codes.datetime.rs: Handles conversion between HighPrecisionDatetime and Arrow timestamps.session.rs: Manages the Session lifecycle (create, start, stop, events).service.rs: Service wrapper for opening services, creating requests, and inspecting schemas.request.rs: Request builder with schema validation.options.rs: SessionOptions for connection, tuning, and keep-alive settings.subscription.rs: SubscriptionList for managing real-time data.correlation.rs: CorrelationId (supporting Int or Pointer variants).identity.rs: Identity handles for authenticated sessions.errors.rs: BlpError enum providing rich error context.Provides introspection into Bloomberg service definitions via operation.rs, element_def.rs, type_def.rs, and constant.rs (for enumerations).
All @xbbg/langgraph tools use the LangChain responseFormat: "content_and_artifact".
When using a ToolNode:
Standard Python-Rust logging bridges (like pyo3-log) often acquire the GIL to forward logs to Python's logging module, which causes latency in high-frequency worker threads.
xbbg-log solves this by:
AtomicLevelFilter that performs a Relaxed load of an AtomicU8. This check takes ~1ns and requires no locks or GIL.stderr via fmt::layer.tracing and Python uses logging independently; there is no bridge between them, preventing GIL contention.By default, lazily connected engines use a hard per-request timeout of 60 seconds (DEFAULT_ENGINE_REQUEST_TIMEOUT_MS). This prevents a wedged Terminal session from hanging tool calls indefinitely. You can customize this via engineConfig:
const tools = createBloombergTools({
engineConfig: { requestTimeoutMs: 30000 } // 30s timeout
});Setting requestTimeoutMs: 0 disables the timeout.
Tools support the LangChain/LangGraph AbortSignal.
xbbg_stream_snapshot, etc.) will stop collecting and unsubscribe immediately (skipping the drain phase) when the signal is aborted.