Overview
create_client_from_uri ffi method is attached without blocking: true, so Ruby-FFI holds the GVL for the entire native call. The native call blocks until the connection is established or the retry strategy gives up, so every other Ruby thread is frozen for that whole window.
create_client is also currently dead code and can be removed.
Expected Behavior
Valkey.new releases the GVL while it waits on the network, so unrelated threads keep running.
Current Behavior
Unrelated threads make no progress until the connect returns or gives up. Against an unreachable host that is the full retry window (seconds), during which timers, health checks and request handlers all stop.
Reproduction Steps
N/A.
Possible Solution
- Add
blocking: true to create_client_from_uri.
- Remove
create_client as it is dead code.
Additional Information/Context
Raised in review comment.
Related but distinct: the GVL-holding-with-callback pattern can deadlock outright, not just stall, when the native call waits on something that needs the GVL. That is not reachable here — the Pub/Sub push handler is spawned after block_on returns (ffi/src/lib.rs:1477), so no callback can fire mid-connect. It is one refactor away from being live, which is part of the argument for fixing the flag now.
Client version used
valkey-glide-rb 1.0.0
Engine type and version
Valkey 8.0
Engine Environment
Local (no server needed — the bug reproduces against an unreachable address)
OS
macOS 26.6.2 (arm64)
Ruby Version
Ruby 3.4.9
Cluster information
N/A — standalone.
Logs
N/A.
Other information
The 16 bindings without blocking: true are not all wrong. Only the create_client* pair blocks; the free_*/drop_* helpers, the OTel span constructors and get_statistics never wait, so annotating them would add handoff cost for no benefit.
Overview
create_client_from_uriffi method is attached withoutblocking: true, so Ruby-FFI holds the GVL for the entire native call. The native call blocks until the connection is established or the retry strategy gives up, so every other Ruby thread is frozen for that whole window.create_clientis also currently dead code and can be removed.Expected Behavior
Valkey.newreleases the GVL while it waits on the network, so unrelated threads keep running.Current Behavior
Unrelated threads make no progress until the connect returns or gives up. Against an unreachable host that is the full retry window (seconds), during which timers, health checks and request handlers all stop.
Reproduction Steps
N/A.
Possible Solution
blocking: truetocreate_client_from_uri.create_clientas it is dead code.Additional Information/Context
Raised in review comment.
Related but distinct: the GVL-holding-with-callback pattern can deadlock outright, not just stall, when the native call waits on something that needs the GVL. That is not reachable here — the Pub/Sub push handler is spawned after
block_onreturns (ffi/src/lib.rs:1477), so no callback can fire mid-connect. It is one refactor away from being live, which is part of the argument for fixing the flag now.Client version used
valkey-glide-rb 1.0.0
Engine type and version
Valkey 8.0
Engine Environment
Local (no server needed — the bug reproduces against an unreachable address)
OS
macOS 26.6.2 (arm64)
Ruby Version
Ruby 3.4.9
Cluster information
N/A — standalone.
Logs
N/A.
Other information
The 16 bindings without
blocking: trueare not all wrong. Only thecreate_client*pair blocks; thefree_*/drop_*helpers, the OTel span constructors andget_statisticsnever wait, so annotating them would add handoff cost for no benefit.