ES6 Generators并发

  1. 云栖社区>
  2. 博客>
  3. 正文

ES6 Generators并发

浣熊干面包 2017-11-19 15:14:00 浏览640
展开阅读全文

ES6 Generators系列:

  1. ES6 Generators基本概念
  2. 深入研究ES6 Generators
  3. ES6 Generators的异步应用
  4. ES6 Generators并发

  如果你已经读过这个系列的前三篇文章,那么你肯定对ES6 generators非常了解了。希望你能从中有所收获并让generator发挥它真正的作用。最后我们要探讨的这个主题可能会让你血脉喷张,让你绞尽脑汁(说实话,写这篇文章让我很费脑子)。花点时间看下文章中的这些例子,相信对你还是很有帮助的。在学习上的投资会让你将来受益无穷。我完全相信,在未来,JS中那些复杂的异步能力将起源于我这里的一些想法。

 

CSP(Communicating Sequential Processes)

  首先,我写这一系列文章完全是受Nolen @swannodette出色工作的启发。说真的,他写的所有文章都值得去读一读。我这里有一些链接可以分享给你:

  好了,让我们正式开始对这个主题的探讨。我不是一个从具有Clojure(Clojure是一种运行在Java平台上的 Lisp 方言)背景转投到JS阵营的程序员,而且我也没有任何Go或者ClojureScript的经验。我发现自己在读这些文章的时候很快就会失去兴趣,因此我不得不做很多的实验并从中了解到一些有用的东西。

  在这个过程中,我觉得我已经有了一些相同的思想,并追求同样的目标,而这些都源自于一个不那么古板的思维方式。

  我尝试创建了一个更简单的Go风格的CSP(以及ClojureScript core.async)APIs,同时我希望能保留大部分的底层功能。也许有大神会看到我文章中遗漏的地方,这完全有可能。如果真是这样的话,我希望我的探索能够得到进一步的发展和演变,而我也将和大家一起来分享这个过程!

 

详解CSP原理(一点点)

  到底什么是CSP?说它是"communicating","Sequential","processes"到底是什么意思呢?

  首先,CSP一词源自于Tony Hoare所著的“Communicating Sequential Processes”一书。里面全是有关CS的理论,如果你对学术方面的东西感兴趣的话,这本书绝对值得一读。我决不打算以一种让人难以理解的,深奥的,计算机科学的方式来阐述这个主题,而是会以一种轻松的非正式的方式来进行。

  那我们就从"Sequential"开始吧!这部分你应该已经很熟悉了。这是另外一种谈论有关单线程和ES6 generators异步风格代码的方式。我们来回忆一下generators的语法:

function *main() {
    var x = yield 1;
    var y = yield x;
    var z = yield (y * 2);
}

  上面代码中的每一条语句都会按顺序一个一个地执行。Yield关键字标明了代码中被阻塞的点(只能被generator函数自己阻塞,外部代码不能阻塞generator函数的执行),但是不会改变*main()函数中代码的执行顺序。这段代码很简单!

  接下来我们来讨论一下"processes"。这个是什么呢?

  基本上,generator函数有点像一个虚拟的"process",它是我们程序的一个独立的部分,如果JavaScript允许,它完全可以与程序的其它部分并行执行。这听起来似乎有点儿荒唐!如果generator函数访问共享内存(即,如果它访问除了自己内部定义的局部变量之外的“自由变量”),那么它就不是一个独立的部分。现在我们假设有一个不访问外部变量的generator函数(在FP(Functional Programming函数式编程)的理论中我们将它称之为一个"combinator"),因此从理论上来说它可以在自己的process中运行,或者说作为自己的process来运行。

  但是我们说的是"processes",注意这个单词用的是复数,这是因为会存在两个或多个process在同一时间运行。换句话说,两个或多个generators函数会被放到一起来协同工作,通常是为了完成一项较大的任务。

  为什么要用多个单独的generator函数,而不是把它们都放到一个generator函数里呢?一个最重要的原因就是:功能和关注点的分离。对于一个任务XYZ来说,如果你将它分解成子任务X,Y和Z,那么在每个子任务自己的generator函数中来实现功能将会使代码更容易理解和维护。这和将函数XYZ()拆分成X()Y(),和Z(),然后在X()中调用Y(),在Y()中调用Z()是一样的道理。我们将函数分解成一个个独立的子函数,降低代码的耦合度,从而使程序更加容易维护。

对于多个generators函数来说我们也可以做到这一点

  这就要说到"communicating"了。这个又是什么呢?就是合作。如果我们将多个generators函数放在一些协同工作,它们彼此之间需要一个通信信道(不仅仅是访问共享的作用域,而是一个真正的可以被它们访问的独占式共享通信信道)。这个通信信道是什么呢?不管你发送什么内容(数字,字符串等),事实上你都不需要通过信道发送消息来进行通信。通信会像合作那样简单,就像将程序的控制权从一个地方转移到另外一个地方。

  为什么需要转移控制?这主要是因为JS是单线程的,意思是说在任意给定的一个时间片段内只会有一个程序在运行,而其它程序都处在暂停状态。也就是说其它程序都处在它们各自任务的中间状态,不过只是被暂停执行,必要时会恢复并继续运行。

  任意独立的"processes"之间可以神奇地进行通信和合作,这听起来有点不靠谱。这种解耦的想法是好的,但是有点不切实际。相反,似乎任何一个成功的CSP的实现都是对那些问题领域中已存在的、众所周知的逻辑集的有意分解,其中每个部分都被特殊设计过从而使得各部分之间都能良好工作。

  或许我的理解完全是错的,但是我还没有看到任何一个切实可行的方法,能够让两个随机给定的generator函数可以以某种方式轻易地聚合在一起形成CSP对。它们都需要被设计成能够与其它部分一起工作,需要遵照彼此间的通信协议等等。

 

JS中的CSP

  在将CSP的理论应用到JS中,有一些非常有趣的探索。前面提到的David Nolen,他有几个很有趣的项目,包括Om,以及core.asyncKoa库(node.js)主要通过它的use(..)方法体现了这一点。而另外一个对core.async/Go CSP API十分忠实的库是js-csp

  你确实应该去看看这些伟大的项目,看看其中的各种方法和例子,了解它们是如何在JS中实现CSP的。

 

异步的runner(..):设计CSP

  因为我一直在努力探索将并行的CSP模式应用到我自己的JS代码中,所以对于使用CSP来扩展我自己的异步流程控制库asynquence来说就是一件顺理成章的事。我写过的runner(..)插件(看上一篇文章:ES6 Generators的异步应用)就是用来处理generators函数的异步运行的,我发现它可以很容易被扩展用来处理多generators函数在同一时间运行,就像CSP的方式那样

  我要解决的第一个设计问题是:如何才能知道哪个generator函数将获得下一个控制权?

  要解决各个generators函数之间的消息或控制权的传递,每个generator函数都必须拥有一个能让其它generators函数知道的ID,这看起来似乎过于笨拙。经过各种尝试,我设定了一个简单的循环调度方法。如果你匹配了三个generators函数A,B和C,那么A将先获得控制权,当A yield时B将接管A的控制权,然后当B yield时C将接管B,然后又是A,以此类推。

  但是如何才能实际转移generator函数的控制权呢?应该有一个显式的API吗?我再次进行了各种尝试,然后设定了一个更加隐式的方法,看起来和Koa有点类似(完全是以外):每个generator函数都获得一个共享"token"的引用,当yield时就表示要将控制权进行转移。

  另一个问题是消息通道应该长什么样。一种是非常正式的通信API如core.async和js-csp(put(..)take(..))。但是在我经过各种尝试之后,我比较倾向于另一种不太正式的方法(甚至都谈不上API,而只是一个共享的数据结构,例如数组),它看起来似乎是比较靠谱的。

  我决定使用数组(称之为消息),你可以根据需要决定如何填充和清空数组的内容。你可以push()消息到数组中,从数组中pop()消息,按照约定将不同的消息存放到数组中特定的位置,并在这些位置存放更复杂的数据结构等。

  我的疑惑是有些任务需要传递简单的消息,而有些则需要传递复杂的消息,因此不要在一些简单的情况下强制这种复杂度,我选择不拘泥于消息通道的形式而使用数组(除数组本身外这里没有任何API)。在某些情况下它很容易在额外的形式上对消息传递机制进行分层,这对我们来说很有用(参见下面的状态机示例)。

  最终,我发现这些generator "processes"仍然得益于那些独立的generators可以使用的异步功能。也就是说,如果不yield控制token,而yield一个Promise(或者一个异步队列),则runner(..)的确会暂停以等待返回值,但不会转移控制权,它会将结果返回给当前的process(generator)而保留控制权。

  最后一点也许是最有争议或与本文中其它库差别最大的(如果我解释正确的话)。也许真正的CSP对这些方法不屑一顾,但是我发现我的选择还是很有用的。

 

一个愚蠢的FooBar示例

  好了,理论的东西讲得差不多了。我们来看看具体的代码:

复制代码
// 注意:为了简洁,省略了虚构的`multBy20(..)`和`addTo2(..)`异步数学函数

function *foo(token) {
    // 从通道的顶部获取消息
    var value = token.messages.pop(); // 2

    // 将另一个消息存入通道
    // `multBy20(..)`是一个promise-generating函数,它会延迟返回给定值乘以`20`的计算结果
    token.messages.push( yield multBy20( value ) );

    // 转移控制权
    yield token;

    // 从CSP运行中的最后的消息
    yield "meaning of life: " + token.messages[0];
}

function *bar(token) {
    // 从通道的顶部获取消息
    var value = token.messages.pop(); // 40

    // 将另一个消息存入通道
    // `addTo2(..)` 是一个promise-generating函数,它会延迟返回给定值加上`2`的计算结果
    token.messages.push( yield addTo2( value ) );

    // 转移控制权
    yield token;
}
复制代码

  上面的代码中有两个generator "processes",*foo()*bar()。它们都接收并处理一个令牌(当然,如果你愿意你可以随意叫什么都行)。令牌上的属性messages就是我们的共享消息通道,当CSP运行时它会获取初始化传入的消息值进行填充(后面会讲到)。

  yield token显式地将控制权转移到“下一个”generator函数(循环顺序)。但是,yield multBy20(value)yield addTo2(value)都是yield一个promises(从这两个虚构的延迟计算函数中返回的),这表示generator函数此时是处于暂停状态直到promise完成。一旦promise完成,当前处于控制中的generator函数会恢复并继续运行。

  无论最终yield会返回什么,上面的例子中yield返回的是一个表达式,都表示我们的CSP运行完成的消息(见下文)。

  现在我们有两个CSP process generators,我们来看看如何运行它们?使用asynquence:

复制代码
// 开始一个sequence,初始message的值是2
ASQ( 2 )

// 将两个CSP processes进行配对一起运行
.runner(
    foo,
    bar
)

// 无论接收到的message是什么,都将它传入sequence中的下一步
.val( function(msg){
    console.log( msg ); // 最终返回42
} );
复制代码

  这只是一个很简单的例子,但我觉得它能很好地用来解释上面的这些概念。你可以尝试一下(试着改变一些值),这有助于你理解这些概念并自己动手编写代码!

 

另一个例子Toy Demo

  让我们来看一个经典的CSP例子,但只是从我们目前已有的一些简单的发现开始,而不是从我们通常所说的纯粹学术的角度来展开讨论。

  Ping-pong。一个很有趣的游戏,对吗?也是我最喜欢的运动。

  让我们来想象一下你已经完成了这个乒乓球游戏的代码,你通过一个循环来运行游戏,然后有两部分代码(例如在ifswitch语句中的分支),每一部分代表一个对应的玩家。代码运行正常,你的游戏运行起来就像是一个乒乓球冠军!

  但是按照我们上面讨论过的,CSP在这里起到了什么样的作用呢?就是功能和关注点的分离。那么具体到我们的乒乓球游戏中,这个分离指的就是两个不同的玩家

  那么,我们可以在一个非常高的层面上用两个"processes"(generators)来模拟我们的游戏,每个玩家一个"process"。当我们实现代码细节的时候,我们会发现在两个玩家之家存在控制的切换,我们称之为"glue code"(胶水代码(译:在计算机编程领域,胶水代码也叫粘合代码,用途是粘合那些可能不兼容的代码。可以使用与胶合在一起的代码相同的语言编写,也可以用单独的胶水语言编写。胶水代码不实现程序要求的任何功能,它通常出现在代码中,使现有的库或者程序在外部函数接口(如Java本地接口)中进行互操作。胶水代码在快速原型开发环境中非常高效,可以让几个组件被快速集成到单个语言或者框架中。)),这个任务本身可能需要第三个generator的代码,我们可以将它模拟成游戏的裁判

  我们打算跳过各种特定领域的问题,如计分、游戏机制、物理原理、游戏策略、人工智能、操作控制等。这里我们唯一需要关心的部分就是模拟打乒乓球的往复过程(这实际上也代表了我们CSP的控制转移)。

  想看demo的话可以在这里运行(注意:在支持ES6 JavaScript的最新版的FireFox nightly或Chrome中查看generators是如何工作的)。现在,让我们一起来看看代码。首先,来看看asynquence sequence长什么样?

复制代码
ASQ(
    ["ping","pong"], // 玩家姓名
    { hits: 0 } //
)
.runner(
    referee,
    player,
    player
)
.val( function(msg){
    message( "referee", msg );
复制代码

  我们初始化了一个messages sequence:["ping", "pong"]{hits: 0}。一会儿会用到。然后,我们设置了一个包含3个processes运行的CSP(相互协同工作):一个*referee()和两个*player()实例。在游戏结束时最终的message会被传递给sequence中的下一步,作为referee的输出message。下面是referee的实现代码:

复制代码
function *referee(table){
    var alarm = false;

    // referee通过秒表(10秒)为游戏设置了一个计时器
    setTimeout( function(){ alarm = true; }, 10000 );

    // 当计时器警报响起时游戏停止
    while (!alarm) {
        // 玩家继续游戏
        yield table;
    }

    // 通知玩家游戏已结束
    table.messages[2] = "CLOSED";

    // 裁判宣布时间到了
    yield "Time's up!";
}
} );
复制代码

  这里我们用table来模拟控制令牌以解决我们上面说的那些特定领域的问题,这样就能很好地来描述当一个玩家将球打回去的时候控制权被yield给另一个玩家。*referee()中的while循环表示只要秒表没有停,程序就会一直yield table(将控制权转移给另一个玩家)。当计时器结束时退出while循环,referee将会接管控制权并宣布"Time's up!"游戏结束了。

  再来看看*player() generator的实现代码(我们使用两个实例):

复制代码
function *player(table) {
    var name = table.messages[0].shift();
    var ball = table.messages[1];

    while (table.messages[2] !== "CLOSED") {
        // 击球
        ball.hits++;
        message( name, ball.hits );

        // 模拟将球打回给另一个玩家中间的延迟
        yield ASQ.after( 500 );

        // 游戏继续?
        if (table.messages[2] !== "CLOSED") {
            // 球现在回到另一个玩家那里
            yield table;
        }
    }

    message( name, "Game over!" );
}
复制代码

  第一个玩家将他的名字从message数组的第一个元素中移除("ping"),然后第二个玩家取他的名字("pong"),以便他们都能正确地识别自己(译:注意这里是两个*player()的实例,在两个不同的实例中,通过table.messages[0].shift()可以获取各自不同的玩家名字)。同时两个玩家都保持对共享球的引用(使用hits计数器)。

  当玩家还没有听到裁判说结束,就“击球”并累加计数器(并输出一个message来通知它),然后等待500毫秒(假设球以光速运行不占用任何时间)。如果游戏还在继续,他们就yield table到另一个玩家那里。就是这样。

  在这里可以查看完整代码,从而了解代码的各部分是如何工作的。

 

状态机:Generator协同程序

  最后一个例子:将一个状态机定义为由一个简单的helper驱动的一组generator协同程序。Demo(注意:在支持ES6 JavaScript的最新版的FireFox nightly或Chrome中查看generators是如何工作的)。

  首先,我们定义一个helper来控制有限的状态处理程序。

复制代码
function state(val,handler) {
    // 管理状态的协同处理程序(包装器)
    return function*(token) {
        // 状态转换处理程序
        function transition(to) {
            token.messages[0] = to;
        }

        // 默认初始状态(如果还没有设置)
        if (token.messages.length < 1) {
            token.messages[0] = val;
        }

        // 继续运行直到最终的状态为true
        while (token.messages[0] !== false) {
            // 判断当前状态是否和处理程序匹配
            if (token.messages[0] === val) {
                // 委托给状态处理程序
                yield *handler( transition );
            }

            // 将控制权转移给另一个状态处理程序
            if (token.messages[0] !== false) {
                yield token;
            }
        }
    };
}
复制代码

  state(..) helper为特定的状态值创建了一个delegating-generator包装器,这个包装器会自动运行状态机,并在每个状态切换时转移控制权。

  依照惯例,我决定使用共享token.messages[0]的位置来保存我们状态机的当前状态。这意味着你可以通过从序列中前一步传入的message来设定初始状态。但是如果没有传入初始值的话,我们会简单地将第一个状态作为默认的初始值。同样,依照惯例,最终的状态会被假设为false。这很容易修改以适合你自己的需要。

  状态值可以是任何你想要的值:numbersstrings等。只要该值可以被===运算符严格测试通过,你就可以使用它作为你的状态。

  在下面的示例中,我展示了一个状态机,它可以按照特定的顺序在四个数值状态间进行转换:1->4->3->2。为了演示,这里使用了一个计数器,因此可以实现多次循环转换。当我们的generator状态机到达最终状态时(false),asynquence序列就会像你所期望的那样移动到下一步。

复制代码
// 计数器(仅用作演示)
var counter = 0;

ASQ( /* 可选:初始状态值 */ )

// 运行状态机,转换顺序:1 -> 4 -> 3 -> 2
.runner(

    // 状态`1`处理程序
    state( 1, function*(transition){
        console.log( "in state 1" );
        yield ASQ.after( 1000 ); // 暂停1s
        yield transition( 4 ); // 跳到状态`4`
    } ),

    // 状态`2`处理程序
    state( 2, function*(transition){
        console.log( "in state 2" );
        yield ASQ.after( 1000 ); // 暂停1s

        // 仅用作演示,在状态循环中保持运行
        if (++counter < 2) {
            yield transition( 1 ); // 跳转到状态`1`
        }
        // 全部完成!
        else {
            yield "That's all folks!";
            yield transition( false ); // 跳转到最终状态
        }
    } ),

    // 状态`3`处理程序
    state( 3, function*(transition){
        console.log( "in state 3" );
        yield ASQ.after( 1000 ); // 暂停1s
        yield transition( 2 ); // 跳转到状态`2`
    } ),

    // 状态`4`处理程序
    state( 4, function*(transition){
        console.log( "in state 4" );
        yield ASQ.after( 1000 ); // 暂停1s
        yield transition( 3 ); // 跳转到状态`3`
    } )

)

// 状态机完成,移动到下一步
.val(function(msg){
    console.log( msg );
});
复制代码

  应该很容易地跟踪上面的代码来查看到底发生了什么。yield ASQ.after(1000)显示了这些generators可以根据需要做任何类型的基于promise/sequence的异步工作,就像我们在前面所看到的一样。yield transition(...)表示如何转换到一个新的状态。上面代码中的state(..) helper完成了处理yield* delegation和状态转换的主要工作,然后整个程序的主要流程看起来十分简单,表述也很清晰流畅。

 

总结

  CSP的关键是将两个或更多的generator "processes"连接在一起,给它们一个共享的通信信道,以及一种可以在彼此间传输控制的方法。

  JS中有很多的库都或多或少地采用了相当正式的方法来与Go和Clojure/ClojureScript APIs或语义相匹配。这些库的背后都有着非常棒的开发者,对于进一步探索CSP来说他们都是非常好的资源。

  asynquence试图采用一种不太正式而又希望仍然能够保留主要结构的方法。如果没有别的 ,asynquence的runner(..) 可以作为你实验和学习CSP-like generators的入门。

  最好的部分是asynquence CSP与其它异步功能(promises,generators,流程控制等)在一起工作。如此一来,你便可以掌控一切,使用任何你手头上合适的工具来完成任务,而所有的这一切都只在一个小小的lib中。

  现在我们已经在这四篇文章中详细探讨了generators,我希望你能够从中受益并获得灵感以探索如何革新自己的异步JS代码!你将用generators来创造什么呢?

 

原文地址:https://davidwalsh.name/es6-generators


本文转自Jaxu博客园博客,原文链接:http://www.cnblogs.com/jaxu/p/6592210.html,如需转载请自行联系原作者


网友评论

登录后评论
0/500
评论
浣熊干面包
+ 关注