Qual è l'esatto ingenuità della pipe Unix

51

Ho sentito la storia di come Douglas Mcllroy ha ideato il concetto e di come Ken Thompson l'ha implementato in una sola notte.

Per quanto ho capito, pipe è una chiamata di sistema che condivide un pezzo di memoria tra due processi in cui un processo scrive e altre letture.

Come qualcuno che non ha familiarità con gli interni oi concetti del sistema operativo, mi chiedevo quale sia esattamente il "genio" nella storia? È l'idea di due processi che condividono la memoria? O è l'implementazione? O entrambi?

PS: sono a conoscenza dell'utilità della pipe o di come usarla nella shell. La domanda riguarda il concetto e l'implementazione di |

    
posta aoak 12.12.2015 - 03:00
fonte

3 risposte

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.

In realtà, non è coinvolta memoria condivisa. Il lettore e lo scrittore NON condividono alcuna parte del loro spazio indirizzo e non stanno utilizzando alcuna sincronizzazione esplicita.

I processi di lettura e scrittura stanno facendo read e write chiamate di sistema esattamente come farebbero se leggessero / scrivessero su un file. Questo è il genio ... l'innovazione: la nozione che (semplice) la comunicazione tra processi e l'I / O di file può essere gestita allo stesso modo ... dal punto di vista del programmatore dell'applicazione e dell'utente.

Una volta che la pipe è stata impostata, il sistema operativo (non il codice dell'applicazione o le librerie nello spazio utente) si occupa del buffering e del coordinamento. In modo trasparente.

Per contro, prima dell'invenzione del concetto di pipe, se avevi bisogno di eseguire l'elaborazione "pipeline", avresti normalmente un output di scrittura dell'applicazione su un file, e poi quando sarà finito, eseguirai la seconda applicazione per leggi dal file.

In alternativa, se si desidera una vera pipeline, è possibile codificare entrambe le applicazioni per impostare un segmento di memoria condivisa (reale) e utilizzare semafori (o qualcosa) per coordinare la lettura / scrittura. Complicato ... e di conseguenza non fatto spesso.

    
risposta data 12.12.2015 - 04:04
fonte
14

Secondo me, il genio dell'idea di "pipe" è la semplicità d'uso.

Non è necessario effettuare chiamate di sistema, allocare memoria, niente di complicato. Nella shell, si usa un singolo carattere: | . Ciò conferisce un potere straordinario nella combinazione di strumenti semplici (o complessi) a un determinato compito.

Prendi alcune attività quotidiane comuni, ad esempio ordinando il testo in modo ordinato. Potresti avere un comando che elenca un sacco di nomi. (Per il mio esempio userò un file che contiene molti nomi, per gentile concessione di listofrandomnames.com.) Usando i pipe puoi fare qualcosa di simile al seguente:

$ 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

Questo è solo un esempio; ce ne sono migliaia Per alcuni altri compiti specifici che sono resi notevolmente più facili dall'uso di pipe, vedi la sezione "The Unix Philosophy" su questa pagina .

Per sottolineare questa risposta, vedere le diapositive da 4 a 9 di la presentazione , "Perché Zsh è più bello della tua shell."

Sono consapevole del fatto che il comando sopra riportato include un UUOC . Lo lascio perché è un segnaposto per un comando arbitrario che genera testo.

    
risposta data 12.12.2015 - 03:41
fonte
5

Quindi ho cercato di fare un po 'di ricerche su questo cercando i manuali di PDP-10 / TOPS-10 per scoprire quale fosse lo stato dell'arte prima delle pipe. Ho trovato questo , ma TOPS-10 è notevolmente difficile da google. Ci sono alcune buone referenze sull'invenzione della pipa: un'intervista con McIlroy , < a href="http://people.fas.harvard.edu/~lib113/reference/unix/unix2.html"> sulla storia e l'impatto di UNIX .

Devi metterlo nel contesto storico. Pochi degli strumenti e delle comodità moderne che diamo per scontato esistevano.

"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."

Un PDP-7 assomiglia a questo . Notare la mancanza di un display interattivo o di un disco rigido. Il "filesystem" verrebbe memorizzato sul nastro magnetico. C'erano fino a 64kB di memoria per programmi e dati.

In quell'ambiente, i programmatori tendevano ad indirizzare direttamente l'hardware, ad esempio emettendo comandi per far ruotare il nastro ed elaborare i caratteri uno alla volta letti direttamente dall'interfaccia del nastro. UNIX forniva astrazioni su questo, in modo che invece di "leggere da teletype" e "read from tape" fossero interfacce separate che erano combinate in una, con l'aggiunta cruciale di "read from output di altri programmi senza memorizzare una copia temporanea su disco o nastro ".

Ecco McIlroy sull'invenzione di grep . Penso che questo faccia un buon lavoro nel riassumere la quantità di lavoro richiesta nell'ambiente pre-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)."

Confronta la prima parte di questo all'esempio di cat names.txt | awk '{print $2 ", " $1}' | sort | uniq | column -c 100 . Se le tue opzioni sono "costruisci una linea di comando" contro "scrivi un programma appositamente per lo scopo, a mano, in assemblatore", allora vale la pena costruire la riga di comando. Anche se ci vogliono alcune ore per leggere i manuali (cartacei) per farlo. Puoi quindi annotarlo per riferimento futuro.

    
risposta data 14.12.2015 - 15:55
fonte

Leggi altre domande sui tag