Alguém forneceria um exemplo de um trabalho síncrono versus assíncrono do Bash?

5

De acordo com o changelog do Bash 4.4:

link

There are a few incompatible changes between bash-4.3 and bash-4.4. Bash now retains the exit status only of asynchronous jobs, as opposed to all jobs. This means that it is not possible to use 'wait' to retrieve the status of a previously-completed synchronous command.

link

Bash only adds asynchronous commands to the table of background pids whose status it remembers, to avoid it growing too large during scripts that create and reap large numbers of child processes. This means that 'wait' no longer works on synchronous jobs, but $? can be used to get the exit status in those cases.

Eu já fui mordido por algumas outras mudanças entre 4.3 e 4.4, mas não sei como escrever um exemplo que testa essa mudança em particular.

Qual é a diferença entre um trabalho síncrono versus um assíncrono no Bash e onde ele armazenou uma tabela de pids a ser consultada por espera?

    
por Zhro 13.01.2017 / 22:04

1 resposta

3

Exemplo:

4,3

bash-4.3$ (echo "$BASHPID"; exit 123)
5358
bash-4.3$ wait 5358; echo "$?"
123

4,4

bash-4.4$ (echo "$BASHPID"; exit 123)
12171
bash-4.4$ wait 12171
bash: wait: pid 12171 is not a child of this shell

Você não pode mais usar wait para obter o status de saída dessa sub-sela que é executada em primeiro plano (de forma síncrona). foreground refere-se a jobs de shells interativos, mas o mesmo se aplica a comandos executados em shells não interativos.

Observe que isso também se aplica a tarefas em segundo plano que depois são colocadas em primeiro plano com fg :

bash-4.4$ (sleep 10; exit 123) &
[1] 12857
bash-4.4$ fg
( sleep 10; exit 123 )
bash-4.4$ wait 12857
bash: wait: pid 12857 is not a child of this shell

Com bash-4.3 e antes, bash se lembraria do status de saída de todos os comandos anteriores de plano de fundo e primeiro plano. Isso não seria útil para os comandos de primeiro plano, como normalmente você não sabe o seu pid no script e também em coisas como:

cmd1 &
...
cmd2
wait "$!"
O pid de

cmd1 poderia muito bem ter sido reutilizado por cmd2 . Nesse caso, wait "$!" obteria o status de saída de cmd2 em vez de cmd1 . Gravar o pid de apenas comandos assíncronos reduz ligeiramente o risco de wait , dando-lhe o status de saída do comando errado (ao lado do problema de desempenho mencionado por @Christopher).

    
por 17.01.2017 / 17:32

Tags