meushell

Fazer o shell executar um comando: criar o processo com fork, trocar o programa com execvp, esperar com waitpid e guardar o código de saída.

As três armadilhas

• execvp que volta é execvp que falhou. Quando dá certo ele não retorna nunca — o programa foi substituído. Se a linha seguinte executou, o comando não existia. É ali que nasce o 127.
• _exit, não exit, no filho. O filho herdou os buffers do pai; exit esvazia esses buffers de novo e o que o pai ainda não imprimiu sai duplicado.
• O filho precisa reagir ao Ctrl-C. O shell ignora o SIGINT para não morrer junto — e o filho herda esse ignorar. Só é cobrado na Entrega 3, mas o lugar de resolver é aqui.

Fazer >, >>, < e | funcionarem. É a entrega em que o descritor de arquivo deixa de ser um número abstrato e vira um recurso do processo.

O &, o jobs, e o Ctrl-C que mata o comando sem matar o shell. É aqui que o sinal aparece pelo que ele é: uma interrupção de software entregue ao processo.

O zumbi transitório — e por que o bash não tem esse problema

Enquanto o shell espera um comando em primeiro plano, o waitpid daquele pid não colhe nenhum outro filho. Um processo de segundo plano que morra nesse intervalo fica zumbi até a próxima linha. Isso é normal para quem colhe antes de cada comando, e é o que o verificador aceita. O jeito profissional é colher quando o SIGCHLD chega — o núcleo avisando na hora. Fazer assim vale bônus.

Três embutidos que rodam um comando e depois contam o que o núcleo registrou sobre ele. É a entrega em que escalonamento e memória virtual param de ser slide e viram número que o programa de vocês imprime.

A chave é o wait4(): igual ao waitpid, com um quarto argumento struct rusage * que o núcleo preenche. O tempo de parede não está lá — esse é você quem mede.

O que os números dizem

O repositório traz três programas. Estes são os valores que eu medi:

A diferença entre parede e CPU é o tempo esperando. E a inversão entre as duas colunas de trocas é o escalonamento aparecendo: quem espera cede a CPU cento e cinquenta vezes; quem calcula quase nunca cede, e é o escalonador que a toma dele.

O terceiro programa, comer, toca 60 MB e registra cerca de 15.430 faltas de página menores. Dividam 60 MB por esse número e vocês descobrem o tamanho da página deste sistema — confiram com getconf PAGESIZE.

Oito minutos por grupo: cinco de demonstração e três de alteração ao vivo.

• O shell rodando (30 s) — ao vivo, a partir do repositório.
• Um processo nascendo (1,5 min) — sleep 60 & e, noutro terminal, o processo na árvore: quem é o pai, qual o estado. Depois matem o pai e mostrem o órfão sendo adotado.
• O cano por dentro (1 min) — ls | wc -l e o /proc/<pid>/fd apontando para pipe:[...].
• Os números da Entrega 4 (2 min) — a tabela dos três programas e a explicação da inversão. Se souberem dizer por que o esperar cede a CPU 150 vezes e o girar quase nunca, vocês entenderam escalonamento.

Na alteração ao vivo cada grupo recebe uma mudança pequena, sorteada na hora, e tem dez minutos: aceitar 2>, marcar no jobs quem já terminou, aceitar dois canos na mesma linha, um embutido que mostra o pid do último processo, ou colher pelo SIGCHLD. Podem consultar tudo — o que não dá para consultar é saber onde mexer.