saída não determinista de processos independentes executados simultaneamente por substituição de processo

Question

Em bash v4.1.2 (2) , a seguinte declaração simples, escolhida meramente como um exemplo mínimo demonstrando o problema, fornece uma saída aparentemente aleatória:

$ for n in {0..1000}; do echo "$n"; done | 
  tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null

Considerando que o seguinte apresenta resultados consistentes:

$ seq 0 10000 | tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null

Especificamente, para a primeira instrução, o comando sort escolhe triplas consecutivas aparentemente aleatórias (por exemplo, 226,225,224; 52,51,50; 174,173,172; etc.). Para ter uma noção da heterogeneidade da saída, pode-se executar o comando problemático várias vezes e, em seguida, listar o número de possibilidades distintas:

$ seq -w 0 2000 | while read x; do for n in {0..1000}; do echo "$n"; done | 
  tee >(head -n2) >(sort -grk1,1 | head -n3) >/dev/null | cat > "file_${x}"; done

Contando as ocorrências das várias saídas:

$ for f in file_*; do sort -g "$f" | tail -n3 | paste -sd, ; done  | 
  sort | uniq -c | sort -gk1,1 -k2,2
   1 7,8,9
   1 17,18,19
   1 40,41,42
   1 43,44,45
   1 47,48,49
   1 50,51,52
   1 54,55,56
   1 58,59,60
   1 59,60,61
   1 66,67,68
   1 71,72,73
   1 78,79,80
   1 103,104,105
   1 104,105,106
   1 106,107,108
   1 110,111,112
   1 111,112,113
   1 121,122,123
   1 125,126,127
   1 129,130,131
   1 134,135,136
   1 136,137,138
   1 142,143,144
   1 143,144,145
   1 148,149,150
   1 150,151,152
   1 156,157,158
   1 157,158,159
   1 165,166,167
   1 171,172,173
   1 173,174,175
   1 174,175,176
   1 177,178,179
   1 179,180,181
   1 181,182,183
   1 183,184,185
   1 185,186,187
   1 186,187,188
   1 191,192,193
   1 194,195,196
   1 198,199,200
   1 200,201,202
   1 206,207,208
   1 208,209,210
   1 209,210,211
   1 210,211,212
   1 216,217,218
   1 217,218,219
   1 233,234,235
   1 236,237,238
   1 237,238,239
   1 238,239,240
   1 242,243,244
   1 245,246,247
   1 246,247,248
   1 254,255,256
   1 256,257,258
   1 267,268,269
   1 270,271,272
   1 273,274,275
   1 277,278,279
   1 279,280,281
   1 287,288,289
   1 288,289,290
   1 305,306,307
   1 306,307,308
   1 307,308,309
   1 326,327,328
   1 337,338,339
   1 339,340,341
   1 340,341,342
   1 351,352,353
   1 357,358,359
   1 359,360,361
   1 365,366,367
   1 368,369,370
   1 370,371,372
   1 376,377,378
   1 377,378,379
   1 383,384,385
   1 386,387,388
   1 388,389,390
   1 401,402,403
   1 408,409,410
   1 409,410,411
   1 415,416,417
   1 419,420,421
   1 424,425,426
   1 426,427,428
   1 432,433,434
   1 454,455,456
   1 462,463,464
   1 466,467,468
   1 475,476,477
   1 482,483,484
   1 487,488,489
   1 504,505,506
   1 508,509,510
   1 511,512,513
   1 532,533,534
   1 538,539,540
   1 544,545,546
   1 548,549,550
   1 558,559,560
   1 603,604,605
   1 604,605,606
   1 608,609,610
   1 659,660,661
   1 660,661,662
   1 663,664,665
   1 668,669,670
   1 692,693,694
   1 699,700,701
   1 717,718,719
   1 738,739,740
   1 740,741,742
   1 750,751,752
   1 771,772,773
   1 784,785,786
   1 796,797,798
   1 799,800,801
   1 806,807,808
   1 814,815,816
   1 832,833,834
   1 848,849,850
   1 858,859,860
   1 869,870,871
   1 922,923,924
   1 952,953,954
   1 961,962,963
   1 985,986,987
   2 64,65,66
   2 127,128,129
   2 141,142,143
   2 169,170,171
   2 170,171,172
   2 172,173,174
   2 187,188,189
   2 221,222,223
   2 234,235,236
   2 252,253,254
   2 292,293,294
   2 350,351,352
   2 364,365,366
   2 375,376,377
   2 622,623,624
   2 666,667,668
   3 70,71,72
   3 102,103,104
   3 137,138,139
   3 155,156,157
1826 998,999,1000

mostra que o resultado está correto ~ 91% do tempo. Omitir a substituição do processo >(head -n2) da instrução tee resulta na saída sendo correta 100% do tempo. Não vejo por que uma condição de corrida seria relevante para explicar o problema, pois isso só afetaria a ordem relativa da saída de cada uma das substituições do processo na instrução tee (ou seja, >(head -n2) pode concluir primeiro ou >(sort -grk1,1 | head -n3) pode fazer isso, mas isso deve afetar apenas a ordem de saída, não o resultado em si; seria até compreensível se a saída dos dois comandos fosse aleatoriamente intercalada). Como tee deve distribuir cópias idênticas do stdout do loop para o stdin de cada >() e desde que ambas as substituições do processo são executadas em sub-shells separadas ( link ), nenhum deve afetar o outro, mas eles claramente interagem. Como a interação pode ser explicada? Além disso, como a saída de um loop for / while em bash pode ser distribuída para vários processos independentes em tee ?

    

Answer 1

head -n2 será encerrado após a leitura de duas linhas. Então tee morrerá (de um SIGPIPE) na próxima vez que gravar no pipe para head , então sort verá eof como tee na outra extremidade de seu próprio tubo também desaparecerá e classificará no canal linhas que recebeu até agora.

O motivo pelo qual você está vendo isso com o loop e não com seq é que o loop faz vários write() s no canal para tee e, dependendo do tempo, isso provavelmente fará com que tee faça várias leituras curtas. Enquanto seq irá gravar toda a saída de uma só vez, tee fará apenas uma read() . Se você fizer um seq 1000000 , provavelmente verá o comportamento aleatório também.

Para contornar o problema, você precisaria de uma versão de head que continue lendo depois de gerar as primeiras duas linhas. Por exemplo, você poderia usar sed '3,$d' em vez de head -n2 ou sed 2q .

Ou use:

... | (
 trap '' PIPE
 exec tee >(trap - PIPE; exec head -n2) >(trap - PIPE; sort -rn | head -n2)
) > /dev/null

para tee (apenas) ignorar o SIGPIPE, mas com algumas implementações tee , você verá algumas mensagens de erro devido à falha write() no canal.

tee: /proc/self/fd/13: I/O error

Observe que, embora a saída classificada seja provável para vir após a não classificada, não há garantia. Em geral, você não pode garantir a ordem de saída dos programas executados simultaneamente, a menos que haja algo que os coordene.