Pipes nomeados do Linux: não tão FIFO quanto se pensava

Isso não tem nada a ver com a semântica FIFO de pipes e não prova nada sobre eles de qualquer maneira. Tem a ver com o fato de que as FIFOs bloqueiam a abertura até que sejam abertas tanto para escrita quanto para leitura; então nada acontece até que seja cataberto fifopara leitura.

já que o primeiro echodeve ser o primeiro.

Iniciar processos em segundo plano significa que você não sabe quando eles serão realmente agendados, portanto, não há garantia de que o primeiro processo em segundo plano fará seu trabalho antes do segundo. O mesmo se aplica ao desbloqueio de processos bloqueados .

Você pode melhorar as chances, enquanto ainda usa processos em segundo plano, atrasando artificialmente o segundo:

rm fifo; mkfifo fifo; echo a > fifo & (sleep 0.1; echo b > fifo) & cat fifo

Quanto maior o atraso, melhores as chances: echo a > fifoblocos esperando para terminar abrindo fifo, catinicia e abre o fifoque desbloqueia echo ae depois echo broda.

Porém o principal fator aqui é quando catabre o FIFO: até então, os shells bloqueiam tentando configurar os redirecionamentos. A ordem de saída vista depende, em última análise, da ordem em que os processos de escrita são desbloqueados.

Você obterá resultados diferentes se executar catprimeiro:

rm fifo; mkfifo fifo; cat fifo & echo a > fifo & echo b > fifo

Dessa forma, a abertura fifopara escrita tenderá a não bloquear (ainda, sem garantias), então você verá aprimeiro com uma frequência maior do que na primeira configuração. Você também verá cato acabamento antes das echo bexecuções, ou seja , apenas aa saída.

Os tubos são primeiro a entrar, primeiro a sair. Seu problema é que você não entende quando o “in” acontece. O evento “in” está escrevendo , não abrindo.

Removendo a pontuação inútil, seu código é:

echo a > fifo & echo b > fifo &

Isso executa os comandos echo a > fifoe echo b > fifoem paralelo. O que quer que entre primeiro sairá primeiro, mas é uma corrida mais ou menos igual para saber quem entra primeiro.

Se você quer aser lido antes b, você tem que providenciar para escrevê-lo antes b. Isso significa que você tem que esperar até que echo a > fifoseja feito antes de começar echo b > fifo.

{ echo a > fifo; echo b > fifo; } & cat fifo

Se você quiser ir mais longe, precisa distinguir entre as operações elementares que acontecem sob o capô. echo a > fifocombina três operações:

1. Aberto fifopara escrita.
2. Escreva dois caracteres ( ae uma nova linha) no arquivo.
3. Feche o arquivo.

Você pode fazer com que essas operações aconteçam em momentos diferentes:

(
    exec >fifo     # 1. open
    sleep 1
    echo a         # 2. write
    sleep 1
)                  # 3. close

Da mesma forma, cat foocombina uma operação de abertura, leitura e fechamento. Você pode separá-los:

(
    exec <fifo     # 1. open
    sleep 1
    read line      # 2. read
    echo $line
    sleep 1
)                  # 3. close

(O readshell embutido pode realmente fazer várias readchamadas de sistema, mas isso não é importante agora.)

Fifos na verdade não são bem tubos. Eles são mais como tubos em potencial. O fifo é uma entrada de diretório e um objeto pipe é criado quando um processo abre o fifo para leitura. Se um processo abre o fifo para escrita enquanto não existe pipe, a openchamada é bloqueada até que um pipe seja criado. Além disso, se um processo abre o fifo para leitura, esta operação também bloqueia até que um processo abra o fifo para escrita (a menos que o leitor abra o pipe no modo não bloqueante, o que não é conveniente do shell). Como consequência, o primeiro aberto para leitura e o primeiro aberto para escrita em um pipe nomeado retornarão ao mesmo tempo.

Aqui está um script de shell que coloca esse conhecimento em ação.

#!/bin/sh
tick () { sleep 0.1; echo tick; echo 0.1; }
mkfifo fifo
{
    exec <fifo; echo >&2 opened for reading;
    echo a; echo >&2 wrote a
} & writer=$!
tick
{
    exec >fifo; echo >&2 opened for writing;
    exec cat >&2;
} & reader=$!
wait $writer
kill $reader
rm fifo

Observe como ambas as aberturas acontecem ao mesmo tempo (o mais próximo que podemos observar). E a escrita só pode acontecer depois disso.

Nota: na verdade, há uma condição de corrida no script acima — mas não está relacionada aos tubos. Os echo >&2comandos estão correndo contra para cat >&2gravar no terminal e, portanto, você pode ver antes e . Se você quiser ter uma visão mais precisa do tempo, você pode rastrear as chamadas do sistema. Por exemplo, no Linux:acatopening for writingwrote a

mkfifo fifo
strace -f -P fifo sh -c '…'

Agora se você colocar dois escritores, ambos os escritores vão bloquear na etapa de abertura até que o leitor chegue. Não importa quem inicia a openchamada primeiro: os pipes são os primeiros a entrar, primeiro a sair, não para tentativas abertas. Quem escreve primeiro é o que importa. Aqui está um script para experimentar isso.

#!/bin/sh
mkfifo fifo
{
    exec >fifo; echo >&2 opened for writing a
    sleep $1
    echo a; echo >&2 wrote a
} & writer_a=$!
{
    exec >fifo; echo >&2 opened for writing b
    sleep $2
    echo b; echo >&2 wrote b
} & writer_b=$!
sleep 0.2
cat fifo & reader=$!
wait $writer_a
wait $writer_b
kill $reader
rm fifo

Chame o script com dois argumentos: o tempo de espera para o leitor a e o tempo de espera para o escritor b. O leitor fica online após 0,2 segundos. Se ambos os tempos de espera forem inferiores a 0,2 segundos, ambos os escritores tentarão escrever assim que os escritores ficarem online, e é uma corrida. Por outro lado, se os tempos de espera forem superiores a 0,2, quem chegar primeiro obtém a saída primeiro.

$ ./c 0.1 0.1
# Order of "opened for writing": random
# Order of "a"/"b": random
# Order of "wrote": random, might not match a/b due to echo racing against each other
$ ./c 0.3 0.4
# Order of "opened for writing": random
# Order of "wrote": a then b
# Order of "a"/"b": a then b