Início / unix / Perguntas / 556386
Accepted
Cyker
Asked: 2019-12-10 09:50:00 +0800 CST

bash: condição de corrida com substituição de pipeline, tee e processo

  • 772

Eu quero ver twicea saída duas vezes, mas este script só produzirá uma vez:

dump() {
    (sleep 1; cat) > "$1"
}
(sleep 0; echo "twice") | tee >(dump "./a.txt")
echo "$(< "a.txt")"

Para vê-lo duas vezes, tenho que ajustar o tempo de sono:

dump() {
    (sleep 0; cat) > "$1"
}
(sleep 1; echo "twice") | tee >(dump "./a.txt")
echo "$(< "a.txt")"

O que causou a condição de corrida aqui?

bash tee

3 respostas

  1. Best Answer

    A dumpchamada na substituição do processo está sendo executada como um processo assíncrono. Isso significa que teegrava sua saída nele e, em seguida, os pipelines são concluídos. O pipeline termina porque a saída de teeé armazenada em buffer; se você escrevesse mais dados do que o tamanho do buffer do pipe , teeteria que esperar para dumpconsumi-lo, e seu código original provavelmente funcionaria.

    Supondo que você escreva apenas uma pequena quantidade de dados, como você faz na pergunta, você lê a.txtimediatamente após o término do pipeline, antes dumpde ter a chance de gravar qualquer coisa no arquivo (ele ainda está dormindo em segundo plano, com os dados pendurados ao redor em um buffer de tubulação).

    Se você examinar o a.txtarquivo depois de executar o código defeituoso, notará que ele contém a string twice. Então, ele chega lá eventualmente, após o pequeno atraso fornecido pela sleep 1função.

    Para impedir que o pipeline termine muito cedo, adicione um catno final:

    dump() {
    (sleep 1; cat) > "$1"
}

(sleep 0; echo "twice") | tee >(dump "./a.txt") | cat
echo "$(< "a.txt")"

    Isso faz com que funcione porque agora o catprocesso precisa esperar que a saída de dumpchegue pelo pipe (não haverá nenhuma, mas ele não sabe disso). Isso atrasa o término do pipeline até que a dumpchamada retorne. Nesse ponto, os dados já foram gravados a.txte podem ser selecionados pelo último comando no script.

    A única coisa que sincroniza os processos em um pipeline é a E/S, ou seja, ler dados do processo anterior e gravar no próximo. Se um processo espera ler da etapa anterior em algum momento, ele bloqueará até que algo esteja disponível para ser lido ou até que a etapa anterior tenha fechado sua extremidade do tubo.

    catlê da entrada padrão por padrão. A entrada padrão do adicionado caté conectada à saída padrão teee à substituição do processo dumpna etapa anterior do pipeline. O catutilitário lerá até que não haja mais nada para ler. Isso não acontece até que ambos teee dumpterminem de executar.

    Versão limpa do código:

    dump() {
    sleep 1
    cat >"$1"
}

echo twice | tee >(dump ./a.txt) | cat

cat a.txt
    • 2 
  2. (sleep 0; echo "twice") | tee >(dump "./a.txt")
echo "$(< "a.txt")"

    IIUC, a questão é como esperar que o processo interno >(...)termine antes de executar a $(...)substituição do comando da próxima linha.

    A resposta é que não há uma maneira legal de fazer isso. Se o seu sistema suporta o /dev/fd/mecanismo, você pode usar um exec fd> >(...)truque:

    dump() {
    (sleep 1; cat) > "$1"
}
echo twice | { exec 7> >(dump a.txt); tee /dev/fd/7; exec 7>&-; wait; }
echo "$(< "a.txt")"

    Sim, isso é muito feio, mas você pode fazer ainda pior:

    echo twice | { a=>(dump a.txt); tee "$a"; eval "exec ${a##*/}>&-"; wait; }

    Como pode ser coletado para isso, a) com versões mais recentes do bash (>= 5.0) você pode waitexecutar os processos internos >(...)e b) esses processos podem não terminar até obter um EOF em seu stdin, o que não acontecerá até você feche a outra extremidade do tubo - o /dev/fd/63ou similar para o >(...)qual se expandiu. Este último é bastante complicado de acertar.

    • 1

  3. Algumas versões do Bash têm um bug de modo que não aguardam corretamente os processos gerados pela substituição do processo.

    • 0

relate perguntas