[zahariash]

This work was produced with the help of language models.

The engine applies the query timeout and per-query thread limit under the mutex a running query holds for its whole duration, so Connection.set_query_timeout() and set_max_threads_for_exec() blocked until the running query finished, and the pybind bindings held the GIL meanwhile, freezing every Python thread: AsyncConnection.set_query_timeout() with 4 long queries in flight froze the event loop for 12-13 s (CPython 3.13/3.14).

Fix. Both setters record the value and return immediately; it is applied before the connection's next execute(), query_as_arrow() or Arrow-table call, latest value wins. The two pybind bindings release the GIL, so a thread that does wait no longer stalls the others.

Tests. Two new tests on a fresh connection: the setters return while a query runs (fails on main: 6.05 s), and applying a pending setting while a query runs does not stall other threads (fails with the old bindings: 6.4 s stall). Both pass here on pybind and C-API. Full suites: no new failures.

Fixes #63

[adsharma]

Review (correctness, CI green, no local build) — logic is sound, no race/deadlock/GIL blocker. Two majors before ship:

1. Validation goes lazy: bad timeout/thread-count used to raise in the setter, now surfaces on the next execute(), misattributed. Suggest validating/coercing eagerly and deferring only the native call.

2. Eager/lazy divergence: _query_timeout_ms is updated eagerly but the native call is deferred, while execute()'s C-API short-circuit reads the eager value — backends disagree in the setter-to-query window. Suggest deferring both or documenting the semantic.

[zahariash]

Thanks — both in faf7159, on top.

• Major 1: setters validate eagerly: operator.index() (TypeError), then 0 <= v < 2**64 (ValueError); only the native call is deferred. The C-API backend never validated (ctypes wrapped -1); pybind raised TypeError for negatives, both now raise ValueError. Tests: each error on both backends, nothing queued.
• Major 2: deferred both. Connection._query_timeout_ms is gone; the C-API short-circuit reads the backend value set when _apply_pending_settings() runs. Docstrings say the value applies from the next query. Test: a cleared timeout applies to the next query.

[adsharma]

Non-blocking follow-up nits (post-rebase verified, content-identical to the merge — no action required before merge):

• set_query_timeout / set_max_threads_for_exec are still @_tracks_call-wrapped, so calling one from inside a UDF raises instead of just queueing a value. Now that setters never touch the engine, the UDF prohibition looks unnecessary for them — either exempt the setters or keep it deliberately.
• _apply_settings_lock is a plain Lock; a reentrant _apply_pending_settings on the same thread would self-deadlock. No current path reenters (native setters never call back into Python), but an RLock would be future-proof for free.
• Pending settings apply to self._connection only, not the auxiliary self._py_connection scan fallback. Pre-existing gap, unchanged here — just noting it.
• bool passes operator.index (True -> 1). Harmless; flagging in case _setting_value is ever tightened.

[zahariash]

Thanks. 1 and 2 go in a follow-up PR after this merges, so the head you verified stays as is.

• I'll drop @_tracks_call from both setters; a shared _queue_setting() will hold self._calls from the _closing check through init_connection() and the queue, so close() can't tear down in between. Tests: a UDF calls both setters and the next query hits the timeout (fails on this head with the UDF error); a setter during a waiting close() raises "Connection is closed."
• RLock: yes, same follow-up.
• Separate issue and PR. On the C-API backend, once _prefer_pybind is set (create_function() and the other pybind-fallback calls, or a Python-object scan that isn't rewritten onto _connection), every later string execute() runs on _py_connection, which gets the constructor's thread limit and neither setting. I'll port an older fix of mine onto the pending settings.
• Keeping bool: both backends accepted True before this PR.