Issue #20587 has been updated by jeremyevans0 (Jeremy Evans). @ivoanjo Thank you for your analysis. I worked on a pull request that handles most of the system calls you listed: https://github.com/ruby/ruby/pull/11147 It doesn't handle `getattrlist` or `fgetattrlist`, because I wasn't able to test with those (they appear to be Mac OS only). Could you test that pull request and see if it addresses the issues you were seeing? If so and it fixes the issues, I can work on `getattrlist` and `fgetattrlist` and rely on CI to check that it works on Mac OS. I can also work on `getpwnam` and other system calls in `process.c` and `ext/etc/etc.c` that are mentioned in the pull request. ---------------------------------------- Bug #20587: dir.c calls blocking filesystem APIs/system calls while holding the GVL https://bugs.ruby-lang.org/issues/20587#change-109060 * 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()`~~, ... see comments for more detailed list...) 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/