Issue #20587 has been updated by jeremyevans0 (Jeremy Evans). @ivoanjo Can you be specific about which places this affects? I examined all `opendir` calls in `dir.c`: * Called in `nogvl_opendir` * Called in `opendir_without_gvl` when VM is not initialized * Called in `nogvl_opendir_at` * Called in `nogvl_dir_empty_p` Tracing those function calls, if the VM is initialized, it appears that all calls use the `IO_WITHOUT_GVL` macro to release the GVL around the call. ---------------------------------------- Bug #20587: dir.c calls blocking filesystem APIs/system calls while holding the GVL https://bugs.ruby-lang.org/issues/20587#change-109017 * Author: ivoanjo (Ivo Anjo) * Status: Open * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Hey! I work for Datadog on the Ruby profiler part of the [`datadog` (previously `ddtrace`)](https://github.com/datadog/dd-trace-rb) gem. While I was investigating https://bugs.ruby-lang.org/issues/20586, I spotted that there's a number of cases where, in `dir.c`, blocking system calls are being made (e.g. `readdir()`, `opendir()`, etc) without releasing the GVL. This means that if they block for a long time (as happens in the gcsfuse example in https://bugs.ruby-lang.org/issues/20586 ), the Ruby VM will just be blocked and not make any progress. The combination of not releasing the GVL + slow system calls actually makes the issue in https://bugs.ruby-lang.org/issues/20586 more likely to happen with the Datadog profiler, although even if the code releases the GVL the underlying issue could still happen, and this is why I decided to file this bug separately. -- https://bugs.ruby-lang.org/