O que acontece quando eu fecho () um descritor de arquivo?

Estou tentando obter uma imagem completa com descritores de arquivo. Digamos que eu possua process1, que inicialmente possui esses descritores de arquivo:

 _process1_
|          |
| 0 stdin  |
| 1 stdout |
| 2 stderr |
|__________|

Então eu fecho o descritor de arquivo 1:

close(1);

O descritor de arquivo 1 converte (pontos) na estrutura FILE stdout na Tabela de Arquivos Abertos do kernel .

Com o código acima, o descritor de arquivo 1 é excluído da tabela do processo, que se torna:

 _process1_
|          |
| 0 stdin  |
| 2 stderr |
|__________|

Mas o que acontece no kernel? A stdoutestrutura FILE é desalocada? Como isso é possível se stdout é um arquivo especial (o monitor) e provavelmente está sendo usado por outros processos? E as estruturas FILE que são apenas arquivos normais (por exemplo, .txt)? E se esse arquivo estiver sendo usado por outro processo?

O descritor de arquivo 1 se traduz na estrutura FILE stdout na Tabela de Arquivos Abertos do Kernel.

Isso é um mal entendido. A tabela de arquivos do kernel não tem nada a ver com estruturas de arquivos no espaço do usuário.

De qualquer forma, o kernel possui dois níveis de indireção. Existe a estrutura interna que representa o próprio arquivo, que é referência contada. Há uma "descrição de arquivo aberto" que é contada como referência. E há o identificador de arquivo, que não é contado como referência. A estrutura do arquivo aponta o caminho para o próprio inode. A descrição do arquivo aberto contém itens como o modo aberto e o ponteiro do arquivo.

Quando você chama close, sempre fecha o identificador do arquivo. Quando um identificador de arquivo é fechado, a contagem de referência em sua descrição de arquivo aberto é diminuída. Se chegar a zero, a descrição do arquivo aberto também será liberada e a contagem de referência no próprio arquivo será diminuída. Somente se for zero, a estrutura de arquivos do kernel será liberada.

Não há chance de um processo liberar um recurso que outro processo está usando porque os recursos compartilhados são contados como referência.

Nesse caso, não acontecerá muita coisa. stdin, stdout e stderr tendem a ser clones do mesmo descritor de arquivo. O contador de referência para o descritor de arquivo será decrementado por um. O mesmo descritor de arquivo geralmente é mantido pelo shell no qual o programa foi executado, portanto, o descritor de arquivo precisa ser mantido.

O kernel mantém contagens de referência para todos os arquivos (inodes) abertos. Enquanto a contagem de referência for maior que zero, o arquivo será mantido. Eu esperaria que um contador separado fosse mantido para identificadores de arquivos abertos. Quando isso atinge zero, o kernel pode liberar a memória usada pelo identificador de arquivo.

Quando todas as referências ao arquivo (entradas de diretório e identificadores de arquivo) forem removidas, o código do sistema de arquivos marcará o inode para reutilização. Quaisquer blocos que o arquivo tenha são disponibilizados para alocação. Muitos sistemas de arquivos limparão os ponteiros de bloco no inode quando ele for liberado. Isso dificulta a recuperação de um arquivo excluído. As atualizações no disco podem ser armazenadas em buffer e concluídas posteriormente.