My team ran into this issue while developing a fuse application too.

In an effort to help this issue move forward, I tried to list all occurrences of the `isatty` C function in the cpython code base. I found 14 of them.

9 of them are directly related to stdin/stdout/stderr, so it's probably not crucial to release the GIL for those occurrences:
- `main.c:stdin_is_interactive`
- `main.c:pymain_import_readline`
- `readline.c:setup_readline`
- `bltinmodule.c:builtin_input_impl` (x2)
- `frozenmain.c:Py_FrozenMain`
- `pylifecycle.c:Py_FdIsInteractive` (x2)
- `fileobject.c:stdprinter_isatty` (GIL is actually released for this one)

Out of the remaining 4, only 1 releases the GIL:
- `fileio.c:_io_FileIO_isatty_impl`: used for `FileIO.isatty`

Which gives 3 occurrences of non-stdstream specific usage of `isatty` that do not release the GIL:
- `posixmodule.c:os_isatty_impl`: used by `os.isatty`
- `fileutils.c:_Py_device_encoding`: used `TextIOWrapper.__init__`
- `fileutils.c:_Py_write_impl`: windows specific, issue #11395

The first one is used by `os.isatty` which means this call can also deadlock. I did manage to reproduce it with a simple fuse loopback file system: https://github.com/fusepy/fusepy/blob/master/examples/loopback.py

The second one is the one found by @smurfix and gets triggered when `io.open()` is used in text mode.

The third one only triggers on windows when writing more than 32767 bytes to a file descriptor. A comment points to issue #11395 (https://bugs.python.org/issue11395). Also, it seems from the function signature that this function might be called with or without the GIL held, which might cause the fix to be a bit more complicated than the first two use cases.

I hope this helps.