Perché le implementazioni CSP coprono solo i canali?

Question

Nel libro Communicating Sequential Processes viene dedicato molto tempo alla definizione degli eventi, che non hanno alcuna direzione e possono coinvolgere più processi indipendenti.

Solo nel capitolo 4 sono introdotti i canali, che sono diretti e coinvolgono 2 processi.

Tuttavia, tutte le implementazioni di CSP inclusi occam, Go, LuaCSP e clojure.core.async implementano solo i canali.

Anche se molti problemi pratici possono essere risolti con i canali (di trasmissione), mi chiedo perché il libro passi così tanto tempo su di loro mentre nessuno li usa.

Answer 1

In Occam-pi, le barriere sono un importante complemento ai canali. Con una barriera, ogni processo registrato attende sulla barriera fino a quando non l'hanno fatto. A questo punto vengono tutti rilasciati. Questo è un esempio di una forma non-channel dell'evento CSP.

Occam-pi ha anche un rendez-vous esteso utilizzando i canali. Questo è un modello piuttosto diverso di utilizzo dei canali, molto simile al rendez-vous in Ada.

Answer 2

Bene prima di tutto il libro happened before le implementazioni. Quindi la tua domanda è meglio formulata come:

Perché nessuna implementazione di CSP ha focalizzato l'attenzione sugli eventi anche se il libro li enfatizza notevolmente.

Fondamentalmente, rendere gli eventi un cittadino di prima classe di una lingua dà una certa specificità di utilizzo che sarebbe probabilmente troppo stretta per un general purpose programming language.

Inoltre, è possibile implementare facilmente eventi su canali (e altri costrutti), nel caso in cui ci si trovi in ​​event driven programming.