Shell Paralelo | PROGRAMAÇÃO
Lançador dinâmico
O esquema mostrado no exemplo 4
é opcional se o tempo de processa-
mento médio para cada item não
variar muito. Porém, não se deve
confiar muito nesse modelo. Por
exemplo, ao converter várias faixas
de um CD, os diferentes compri-
mentos de cada uma farão com que
alguns processos terminem antes dos
outros. Outra situação em que essa
abordagem pode ser problemática
é a conversão de imagens a partir
de uma câmera digital. Algumas câ-
meras criam arquivos de miniatura
ou JPEG além dos arquivos raw. Se
cada um dos demais arquivos usar
o formato raw e precisar ser con-
vertido, metade dos processos de
conversão terminarão muito antes
porque o esquema de processamento
atribui todos os arquivos raw a um
único processo e todos os arquivos
JPEG a outro.
O método de processamento no
exemplo 4 também será prejudicado
se nem todos os argumentos forem
declarados com antecedência. Se os
argumentos gerados posteriormente
Figura 2 O lançador e os processos auxiliares usam pipes para se comunica-
rem.
Linux Magazine #51 | Fevereiro de 2009
Figura 1 A saída do sar mostra a carga em todos os processadores. A
paralelização só faz sentido se alguns núcleos estiverem sobrecarre-
gados enquanto outros estiverem ociosos.
no script acontecerem em sequência,
não faz sentido esperar até que todos
sejam criados e então distribuí-los
pelos processos.
A solução para esse problema é
usar processos auxiliares e um lan-
çador dinâmico. Nesse cenário, o
script dispara certo número de pro-
cessos auxiliares. O lançador aceita
as tarefas e as distribui da forma mais
inteligente possível para os auxilia-
res. Em contraste com as soluções
paralelas demonstradas anterior-
mente, em que todos os processos
auxiliares precisavam receber todos
os argumentos no início, o lançador
repassa-os aos auxiliares depois que
eles iniciaram.
Pipes nomeados (named pipes)
e FIFOs são utilizados como ca-
nais de comunicação. No início, o
lançador abre um pipe para cada
auxiliar e envia novas tarefas para
esse pipe (figura 2). Outro pipe é
compartilhado pelo lançador e pe-
los auxiliares e age como um canal
de retorno. Quando um auxiliar
se torna ocioso, escreve seu ID no
pipe. O lançador lê o ID do auxiliar
no pipe após cada tarefa e envia a
próxima tarefa para ele.
O exemplo 5 mostra uma imple-
mentação desse conceito. Nas linhas
1 a 4, o programa define algumas
constantes caso isso ainda não tenha
sido feito. Normalmente, o usuá-
rio define apenas a variável _cmd. A
função dispatchWork nas linhas 54 a
72 é a parte pública da interface. A
função começa criando um diretório
temporário para todos os pipes na
75