Qual é a ingenuidade exata do tubo Unix?

51

Eu ouvi a história de como Douglas Mcllroy surgiu com o conceito e como Ken Thompson o implementou em uma noite.

Tanto quanto eu entendo, pipe é uma chamada de sistema que compartilha uma parte da memória entre dois processos onde um processo grava e outras leituras.

Como alguém que não é familiarizado com sistemas internos ou conceitos de SO, fiquei me perguntando o que exatamente é o "gênio" da história? É a idéia de dois processos compartilhando memória? Ou é a implementação? Ou ambos?

PS: Estou ciente do utilitário do pipe ou como usá-lo no shell. A questão é sobre conceito e implementação do |

    
por aoak 12.12.2015 / 03:00
fonte

3 respostas

107

As far as I understand, pipe is a system call which shares a piece of memory between two processes where one process writes and other reads from.

Na verdade, não há memória compartilhada envolvida. O leitor e o escritor NÃO estão compartilhando qualquer parte de seu espaço de endereço e não estão usando nenhuma sincronização explícita.

Os processos de leitura e gravação estão fazendo read e write chamadas do sistema exatamente como se estivessem lendo / gravando em um arquivo. Esse é o gênio ... a inovação: a noção de que a comunicação (simples) entre processos e a E / S de arquivos pode ser tratada da mesma maneira ... da perspectiva do programador de aplicativos e do usuário.

Depois que o canal tiver sido configurado, o sistema operacional (não o código do aplicativo ou as bibliotecas no espaço do usuário) cuidará do armazenamento em buffer e da coordenação. Transparentemente.

Por contraste, antes da invenção do conceito de pipe, se você precisasse realizar o processamento de "pipeline", normalmente teria uma saída de gravação de aplicativo em um arquivo e, quando terminasse, executaria o segundo aplicativo para ler do arquivo.

Como alternativa, se você quiser um pipeline verdadeiro, poderá codificar os dois aplicativos para configurar um segmento de memória compartilhada (real) e usar semáforos (ou algo assim) para coordenar a leitura / gravação. Complicado ... e consequentemente não é feito com frequência.

    
por 12.12.2015 / 04:04
fonte
14

Na minha opinião, o gênio da idéia de "pipes" é a simplicidade de uso.

Você não precisa fazer nenhuma chamada de sistema, alocar memória, nada complicado. No shell, você usa um único caractere: | . Isso dá um poder extraordinário na combinação de ferramentas simples (ou complexas) para uma determinada tarefa.

Participe de algumas tarefas comuns do dia a dia, como classificar o texto de maneira organizada. Você pode ter um comando que lista um monte de nomes. (Para o meu exemplo, vou usar um arquivo que contém vários nomes, cortesia de listofrandomnames.com.) Usando pipes, você pode fazer algo como o seguinte:

$ cat names.txt
Sally Weikel
Dana Penaflor
Christine Hook
Shaneka Flythe
Almeda Crook
Freddie Lindley
Hester Kersh
Wanda Ruse
Megan Mauzy
Samuel Mancha
Paris Phipps
Annika Accardo
Elena Nabors
Caroline Foti
Jude Nesby
Chase Gordy
Carmela Driggers
Marlin Ostendorf
Harrison Dauber
$ cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100
Accardo, Annika     Hook, Christine     Ostendorf, Marlin
Crook, Almeda       Kersh, Hester       Penaflor, Dana
Dauber, Harrison    Lindley, Freddie    Phipps, Paris
Driggers, Carmela   Mancha, Samuel      Ruse, Wanda
Flythe, Shaneka     Mauzy, Megan        Weikel, Sally
Foti, Caroline      Nabors, Elena
Gordy, Chase        Nesby, Jude

Este é apenas um exemplo; existem milhares. Para algumas outras tarefas específicas que são incrivelmente mais fáceis com o uso de pipes, veja a seção "The Unix Philosophy" em esta página .

Para destacar essa resposta, consulte os slides de 4 a 9 da apresentação , "Por que o Zsh é mais legal que o seu Shell".

Estou ciente de que o comando acima inclui um UUOC . Deixei isso porque é um espaço reservado para um comando arbitrário que gera texto.

    
por 12.12.2015 / 03:41
fonte
5

Então eu tentei fazer uma pequena pesquisa sobre isso procurando por manuais do PDP-10 / TOPS-10 para descobrir o que era o estado da arte antes dos tubos. Eu encontrei isso , mas TOPS-10 é incrivelmente difícil de pesquisar no google. Existem algumas boas referências sobre a invenção do cachimbo: uma entrevista com McIlroy < href="http://people.fas.harvard.edu/~lib113/reference/unix/unix2.html"> no histórico e impacto do UNIX .

Você tem que colocar isso no contexto histórico. Poucas das ferramentas e conveniências modernas que tomamos como garantidas existiam.

"At the start, Thompson did not even program on the PDP itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine."(29) A paper tape was generated on the GE 635 and then tested on the PDP-7 until, according to Ritchie, "a primitive Unix kernel, an editor, an assembler, a simple shell (command interpreter), and a few utilities (like the Unix rm, cat, cp commands) were completed. At this point, the operating system was self-supporting, programs could be written and tested without resort to paper tape, and development continued on the PDP-7 itself."

Um PDP-7 se parece com isso . Observe a falta de um display interativo ou disco rígido. O "sistema de arquivos" seria armazenado na fita magnética. Houve até 64kB de memória para programas e dados.

Nesse ambiente, os programadores tendiam a abordar o hardware diretamente, por exemplo, emitindo comandos para girar a fita e processar os caracteres, um de cada vez, lidos diretamente da interface de fita. O UNIX forneceu abstrações sobre isso, de modo que, em vez de "ler do teletipo" e "ler da fita" serem interfaces separadas, elas foram combinadas em uma, com a adição crucial de "leitura da saída de outro programa sem armazenar uma cópia temporária no disco". ou fita ".

Aqui está McIlroy sobre a invenção de grep . Acho que isso faz um bom trabalho resumindo a quantidade de trabalho necessária no ambiente pré-UNIX.

"Grep was invented for me. I was making a program to read text aloud through a voice synthesizer. As I invented phonetic rules I would check Webster's dictionary for words on which they might fail. For example, how do you cope with the digraph 'ui', which is pronounced many different ways: 'fruit', 'guile', 'guilty', 'anguish', 'intuit', 'beguine'? I would break the dictionary up into pieces that fit in ed's limited buffer and use a global command to select a list. I would whittle this list down by repeated scannings with ed to see how each proposed rule worked."

"The process was tedious, and terribly wasteful, since the dictionary had to be split (one couldn't afford to leave a split copy on line). Then ed copied each part into /tmp, scanned it twice to accomplish the g command, and finally threw it away, which takes time too."

"One afternoon I asked Ken Thompson if he could lift the regular expression recognizer out of the editor and make a one-pass program to do it. He said yes. The next morning I found a note in my mail announcing a program named grep. It worked like a charm. When asked what that funny name meant, Ken said it was obvious. It stood for the editor command that it simulated, g/re/p (global regular expression print)."

Compare a primeira parte disso com o exemplo cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100 . Se suas opções são "construir uma linha de comando" versus "escrever um programa especificamente para o propósito, manualmente, em assembler", então vale a pena construir a linha de comando. Mesmo que leve algumas horas lendo os manuais (de papel) para fazer isso. Você pode então escrevê-lo para referência futura.

    
por 14.12.2015 / 15:55
fonte