Leia com mais cuidado fechar (2) e Programação avançada do Linux
Sua formulação está errada: o fechamento é uma chamada de sistema (listada em syscalls (2) para Linux) pelo qual o aplicativo informa ao kernel para liberar um recurso (e não o contrário). Você pode usar strace (1) para entender as chamadas do sistema executadas por algum comando ou processo . Veja também pthreads (7) , credenciais (7) , fork (2) , execve (2) , clone (2)
E sim, descritores de arquivos (e espaço de endereço na memória virtual , consulte mmap (2) ) são comuns a todos os encadeamentos de um determinado process . No entanto, você pode (raramente) criar "encadeamentos" diretamente com o clone de baixo nível (2) syscall (que na prática é apenas usado por implementadores de bibliotecas de threads como pthreads ), e no caso improvável você não é usado CLONE_FILES as coisas são diferentes. Mas chamar diretamente clone é uma arte de magia negra.
Para um determinado processo de pid 1234, no Linux, você pode consultar o conjunto de descritores de arquivos (em proc (5) ) através de /proc/1234/fd/ e o mapeamento de memória através de /proc/1234/maps (etc etc ... existem muitos arquivos e links pseudo em /proc/1234 ). De dentro do processo, você pode usar /proc/self/fd/ - por exemplo, como argumento para opendir (3)
É claro que os descritores de arquivos são muito mais do que um padrão POSIX ou Linux, do que um padrão C99 ou C ++ 11 1. Por exemplo, fileno (3) & O open é definido no POSIX, não no C99.
Então, se você vir um determinado número -e.g. 49- foi retornado por open varias vezes porque alguma outra parte do seu programa (talvez dentro de alguma biblioteca, em outro thread) chamou close com 49. O kernel nunca "magicamente" fecha descritores de arquivos (exceto em finalização do processo) sem ser solicitado. Você pode usar strace ou usar seu depurador gdb com um ponto de interrupção (provavelmente um condicional) em close