有个梨UGlee
2019-12-28 02:07:21 发布
本质上我们在程序里写的是process，是process calculus意义上的那个，如果不清楚这个概念把process理解成一个有态有行为的抽象对象即可。这包括函数和程序语言意义上的对象。

一个process在结束时，会给另一个process发送message，这是我们组合process构成复杂程序的基础手段。

对于最常见的一个函数调用了另一个函数，被调用的函数返回可以看作这个process结束，发送了一个message。

当然理想情况下是结果，但也有可能出现错误。抽象的逻辑是，用于继续的process有两个！一个是继续正确结果的，另一个是继续错误的，这两个process是二选一执行，换句话说是互斥的。在pi calculus里这两个progress的运算符是➕，叫summation。

这个符号几乎是写并发时最重要的进程运算符号，但是，特娘的，在所有流行编程语言里都妹有。

我拿node说个例子，比如emitter，用户最需要写出多个event handler的代码，只要其中一个fire，其它的自动被取消，这个当然能手写出来，但是巨烦琐。所以node里充斥着removeListener这样的代码。而概念上，他们只是表达了一个continuation的互斥关系。

++++

在计算机还没有跟IO打交到，程序是所谓的sequential process的年代，程序被看作是pure function；在出现IO以及其它现代系统的诸多并发特性后，这种函数形式被保留下来了。Unix和C的设计目标是「虚拟」一个看起来象sequential program的东西，即一个process，操作系统意义上的。

在这种设计下，两个互斥的handler，或者说process calculus意义上的process，被代码层面强行merge成了一个block或scope里的代码。这是噩梦的真正原因。否则只是一个error handler装在哪里（做谁的continuation）的问题。

++++

Benjamin Pierce搞了一个基于pi calculus的语言，但是它的处理方式更类似go的CSP；我的理解是，在语言层面这样理解channel是错的，太重了，现有语言的reference都是channel，我们需要的是一个continuation的互斥（包括条件互斥）的表达式而不是go的那种channel。

++++

在这样的语言出现之前，我能想到的可做的就是代码中没有形式体现，但是心中（设计上）分离error处理路径和result处理路径，代码层面巨繁琐且易错，互斥路径互相拔掉对方的handler。

my 2 cent @遊真·uZen