Segundo Semestre
de 2009 Prof.
Wagner M. Nunan Zola
Trabalho 1 - versão 1.2
(correcões da versão 1, em vermelho)
histórico
das versões:
v1.0
especific. inicial
v1.1
correcões no texto de otube (em
vermelho)
v1.2 figuras
inseridas na versão html
Data
de Entrega:
23/out/2009 (adiado para
até 30/out) Equipe:
3 ou 4 componentes Importante:
o nome da equipe e dos integrantes deve ser comunicado previamente ao professor por escrito, em papel
assinado pelos membros, em sala de aula, até 20 dias antes da entrega.
Trabalhos não "inscritos" previamente não serão
considerados.
Composições
alternativas de processos com pipes.
Motivação:
O objetivo do trabalho 1 é
implementar pequenos programas utilitarios em Unix para excutar
sistemas de processos que se comunicam via pipes utilizando
padrões alternativos, que não são suportados
diretamente pelas shells comuns.
A principal
motivação para esse trabalho é a prática de
programação com sistemas de processos no Linux (ou Unix)
e de conceitos como: fork, exec, signals, pipes,
comunicação entre processos e leitura de parametros na
linha de comandos (via argc, argv). Como esse é apenas um
exercício sobre esses conceitos, não significa que a
arquitetura especificada seja a melhor possível, mas que podemos
utilizar essas funções do sistema na
implementação da tarefa.
As ferramentas são bastante simples, ao estilo de Unix, pequenas
ferramentas com funções específicas
com possibilidade de composição de processos via pipes.
Assim, cada grupo deve escrever o código
de 4 ou 5 pequenas ferramentas cuja programação fica em
cerca de 2 ou 3 páginas cada, tornando o trabalho menos complexo.
Programa 1) Interface:
itube p1 [ + p2 + ... + pn ] :- z
Obs:
[ ] indicam parâmetros
opcionais ( [] não fazem parte da entrada )
p1, p2, ... pn e z são nomes de programas a serem executados
pelo programa itube
+ é um
separador opcional, deve ser digitado somente se existe mais de 1
programa do tipo pn :- é um separador,
deve ser digitado obrigatóriamente na linha de comando,
deve ser usado para indicar o último programa.
Efeito: O programa itube deve criar um pipe
e executar os processos indicados na linha de comando.
Os processos devem ser conectados via pipe pelo programa itube
(antes
do exec) de modo
que a saida padrão dos processos p1 ... pn deve ir para o pipe e
a entrada padrão do processo z deve vir do pipe. (Fig.1 e
exemplo abaixo)
Exemplo 1:
itube
w + x + y :- z
(fig
1, desenhada inicialmente no
quadro, reproducão abaixo)
Programa 2) Interface:
otube a :- p1 [ + p2 + ... + pn ]
Obs:
[ ] indicam parâmetros
opcionais ( [] não fazem parte da entrada )
a, p1, p2, ... pn são nomes de programas a serem
executados pelo programa otube
+ é um
separador opcional, deve ser digitado somente se existe mais de 1
programa do tipo pn :- é um separador,
deve ser digitado obrigatóriamente na linha de comando,
deve ser usado para indicar o último programa.
Efeito: O programa otube deve criar um pipe
e executar os processos indicados na linha de comando.
Os processos devem ser conectados via pipe pelo programa otube (antes
do exec) de modo
que a entrada padrão dos
processos p1 ... pn deve vir do o pipe
e
a
saida padrão do processo a(interface acima) deve ir para o
pipe. (Fig.2 e exemplo
abaixo)
Exemplo 2:
otube
z :- w + x + y
(fig
2, desenhada inicialmente no
quadro, reproducão abaixo)
Programa 3) Interface:
utube p1 -:- p2
Obs: p1 e p2 são nomes de
programas a serem executados pelo programa utube -:- é um separador, deve ser
digitado obrigatóriamente na linha de comando,
deve ser usado para indicar a
separação o pipe duplo os pogramas.
Efeito: O programa utube deve criar dois
pipes e executar os processos indicados na linha de comando.
Os processos devem ser conectados via pipe pelo programa utube (antes
do exec) de modo
que a saida padrão do processo p1 deve ir para o pipe1 e a
sua entrada padrão deve vir do pipe2. A saida padrão do
processo p2 deve ir para o pipe2 e a
sua entrada padrão deve vir do pipe1. (Fig.3 e exemplo abaixo)
Exemplo 3:
utube
x -:- y
(fig
3, desenhada inicialmente no
quadro, reproducão abaixo)
Programa 4) Interface:
pitcher n s pid
Obs: n s e pid são
números inteiros
Efeito: O programa pitcher envia n vezes o
sinal s para o processo pid. (i.e. uma rajada de sinais)
Programa 5) Interface:
catcher n s
Obs: n e s são
números inteiros
Efeito: O programa cather recebe n vezes o
sinal s (i.e. espera n entregas de sinal)
Para cada sinal s recebido imprime em stdio, um aviso por linha: [sinal s recebido]
onde s é o número do sinal.
Implementações:
OBS: mais dicas
sobre implementações poderão ser incluidas aqui em
breve
Todos os programas devem ser
escritos em linguagem C (justificativa). O processo pai (e.g. itube, etc)
deve
"disparar" varios outros processos (filhos) via chamadas fork() e
qualquer variação de exec (caso necessário).
Os programas devem suportar mais comandos na linha que devem ser
passados aos filhos em
via argc e argv, na criacao (ou exec) dos filhos.
exemplo:
itube ls -la
:- more
A comunicação
pai-filho deve ser feita com pipe(s), alem de argc e argv. Esses pipes
devem ser criados pelo programa pai (e
não externamente por qualquer shell).
O
sistema de processos (pai e
filhos) não deve gerar processos "zombies", caso seja possível em Linux.
Caso contrário, os zombies devem ter "existência" mais breve possível (pois
esses ocupam um pequeno de espaço de memória na
"tabela" de processos).
O sistema deve funcionar, e poder
ser compilado, nas servidoras de processamento do DINF/UFPR.
Deve ser o mais simples
possível. A eficiência desse algoritmo não é
o objetivo principal desse trabalho.
OBS: mais
dicas sobre implementações:
a função pipe deve ser mais indicada para esse
trabalho. Considere tambem a função dup2 (ou dup), que
deverão ser úteis. A função popen não deve ser adequada.
OBS: mais
dicas sobre implementações poderão ser incluidas
aqui em breve
Entrega:
A entrega deve ser eletrônica:
codigo(s) fonte, scripts de compilação e relatório
breve das implementação e principais decisões de
projeto, em formato html, no mesmo diretório). O documento html
também deve fazer referêcia aos aquivos fonte, descrver o
propoósito de cada arquivo, e possuir um "link" para os mesmos.
A descrição completa
do protocolo da entrega estará [aqui]. O diretório de entrega deve
conter um script de nome "compila" (sem aspas), que poderá ser usado para
compilar o que for necessário para o código.
Um nome deve ser dado a cada equipe.
O nome da equipe e de seus integrantes deve estar no relatório
entregue. Não haverá entrega em papel. Cada integrante deverá ser
capaz de responder perguntas sobre o sistema (nas provas), arquitetura,
decisões de projeto, codificar ou modificar pequenas partes do
mesmo. Cada componente da equipe pode variar sua nota de trabalho em
até 40% com referêcia a questionamentos sobre o trabalho.
60% da nota será comum à equipe.
Sobre o relatório e algumas
experiencias:
O relatorio deve incluir também respostas para algumas perguntas
que serão colocadas
aqui em breve. Algumas dessas perguntas podem ser respondidas depois de
pequenas experiencias
a serem realizadas com os programas.
