Como um FIFO (pipe nomeado) difere de um tubo regular (pipe sem nome)? [duplicado]

"Pipe nomeado" é na verdade um nome muito preciso para o que é - é como um pipe normal, exceto que tem um nome (em um sistema de arquivos).

Um canal — o regular, sem nome ("anônimo") usado em some-command | grep patterné um tipo especial de arquivo. E eu quero dizer arquivo, você lê e escreve nele como faz com qualquer outro arquivo. O Grep realmente não se importa¹ se está lendo de um canal em vez de um terminal³ ou um arquivo comum.

Tecnicamente, o que acontece nos bastidores é que stdin, stdout e stderr são três arquivos abertos (descritores de arquivo) passados ​​para cada execução de comando. Os descritores de arquivo (que são usados ​​em cada syscall para ler/escrever/etc. arquivos) são apenas números; stdin, stdout e stderr são descritores de arquivo 0, 1 e 2. Portanto, quando seu shell configura, o some-command | grepque ele faz é algo assim:

1. Pede ao kernel um canal anônimo. Não há nome, então isso não pode ser feito opencomo para um arquivo normal - em vez disso, é feito com pipeou pipe2, que retorna dois descritores de arquivo.⁴

2. Bifurca um processo filho ( fork()cria uma cópia do processo pai; ambos os lados do pipe estão abertos aqui), copia o lado de gravação do pipe para fd 1 (stdout). O kernel tem um syscall para copiar os números do descritor de arquivo; é dup2()ou dup3(). Em seguida, fecha o lado de leitura e outra cópia do lado de gravação. Finalmente, ele usa execvepara executar some-command. Como o tubo é fd 1, stdout some-commandé o tubo.

3. Forks de outro processo filho. Desta vez, ele duplica o lado de leitura do pipe para fd 0 (stdin) e executa grep. Portanto, o grep lerá o pipe como stdin.

4. Em seguida, espera que ambas as crianças saiam.

5. Nesse ponto, o kernel percebe que o canal não está mais aberto e o lixo o coleta. Isso é o que realmente destrói o tubo.

Um pipe nomeado apenas dá um nome a esse pipe anônimo, colocando-o no sistema de arquivos. Portanto, agora qualquer processo, em qualquer ponto no futuro, pode obter um descritor de arquivo para o canal usando uma chamada de sistema comum open. Conceitualmente, o canal não será destruído até que todos os leitores/gravadores o fechem e ele seja unlinkremovido do sistema de arquivos.²

A propósito, é assim que os arquivos em geral funcionam no Unix. unlink(o syscall atrás rmde ) apenas remove um dos nomes do arquivo; somente quando todos os nomes forem removidos e nada tiver o arquivo aberto, ele será realmente excluído. Algumas respostas aqui exploram isso:

• Por que os hard links parecem ocupar o mesmo espaço que os originais?
• Como um programa de log pode continuar registrando em um arquivo excluído?
• O que o Linux está fazendo de diferente que me permite remover/substituir arquivos onde o Windows reclamaria que o arquivo está em uso?

NOTAS DE RODAPÉ

1. Tecnicamente, isso provavelmente não é verdade - provavelmente é possível fazer algumas otimizações sabendo, e as implementações reais do grep geralmente foram fortemente otimizadas. Mas conceitualmente isso não importa (e, de fato, uma implementação direta do grep não importaria).
2. É claro que o kernel não mantém todas as estruturas de dados na memória para sempre, mas as recria, de forma transparente, sempre que o primeiro programa abre o canal nomeado (e então as mantém enquanto estiver aberto). Então é como se eles existissem desde que o nome existe.
3. O terminal não é um lugar comum para o grep ler, mas é o stdin padrão quando você não especifica outro. Portanto, se você digitar apenas grep patternno seu shell, grepestará lendo no terminal. O único uso para isso que vem à mente é se você estiver prestes a colar algo no terminal.
4. No Linux, pipes anônimos são criados em um sistema de arquivos especial, pipefs. Consulte Como os pipes funcionam no Linux para obter detalhes. Observe que este é um detalhe de implementação interna do Linux.

Acho que você está se confundindo entre a sintaxe do shell para pipelines e a programação subjacente dos sistemas Unix. Um pipe / FIFO é um tipo de arquivo que não é armazenado em disco, mas passa dados de um gravador para um leitor por meio de um buffer no kernel.

Um pipe/FIFO funciona da mesma forma se o gravador e o leitor se conectaram fazendo chamadas de sistema como open("/path/to/named_pipe", O_WRONLY);, ou com um pipe(2)para criar um novo pipe anônimo e retornar descritores de arquivo aberto para os lados de leitura e gravação.

fstat(2)no descritor de arquivo de canal fornecerá a você sb.st_mode & S_IFMT == S_IFIFOde qualquer maneira.

Quando você correfoo | bar :

• O shell se bifurca como normal para qualquer comando não integrado
• Em seguida, faz uma pipe(2)chamada de sistema para obter dois descritores de arquivo: a entrada e a saída de um pipe anônimo.
• Então ele se bifurca novamente .
• A criança (onde fork()retornou 0)
  • fecha o lado de leitura do pipe (deixando o fd de gravação aberto)
  • e redireciona stdoutpara o fd de gravação comdup2(pipefd[1], 1)
  • então fazexecve("/usr/bin/foo", ...)
• O pai (onde fork()retornou o PID filho diferente de 0)
  • fecha o lado de escrita do pipe (deixando o read fd aberto)
  • e redireciona stdindo read fd comdup2(pipefd[0], 0)
  • então fazexecve("/usr/bin/bar", ...)

Você entra em uma situação muito semelhante se correr foo > named_pipe & bar < named_pipe.

Um pipe nomeado é um ponto de encontro para processos estabelecerem pipes entre si.

A situação é semelhante a arquivos tmp anônimos versus arquivos com nomes. Você pode open("/path/to/dir", O_TMPFILE | O_RDWR, S_IRUSR | S_IWUSR);criar um arquivo temporário sem nome ( O_TMPFILE), como se tivesse aberto "/path/to/dir/tmpfile"com O_CREATe depois desvinculado, deixando você com um descritor de arquivo para um arquivo excluído.

Usando linkat, você pode até vincular esse arquivo anônimo ao sistema de arquivos, dando-lhe um nome, se tiver sido criado com O_TMPFILE. ( Você não pode fazer isso no Linux para arquivos que você criou com um nome e depois deletado. )