z****e
发帖数: 54598 | 1 尝试着回答一下这个问题
1）做不到比os native的更好，但是问题在于，有些操作系统根本就没有cooperative
sheduling，比如linux，如果有的话，直接做一层包装就好了，但是没有的话，就只能
让语言来做了
2）不靠机器码，但是靠字节码，基本上就差不多了，光靠当前java的api，是不够的，
需要加多一个context参数，参考kotlin的coroutine实现，或者是通过java agent_织
入_一些context代码，这就是quasar的实现，这也是loom名称的由来
3）强在哪里呢
嗯，这个说来话长，说说我的理解
wdong有一篇回帖，解释了os层面cooperative scheduling和preemptive scheduling的
区别，有空自己去找，但是我觉得他说得复杂了，当然也因为后来用户层面框架的发展
，比如actor model有关系，看看我能不能解释清楚，这一块涉及的东西太多，os&jvm
和vert.x/actor model乃至开发者自身，都有需要配合的部分，任何一个部分不能掉链
子，所以解释起来不容易
先说os&jvm层面，这个是... 阅读全帖 |
|
z****e
发帖数: 54598 | 2
经常
停止这种无意义的blablabla吧？
我们上点能够测量的
我就这么说vert.x+java性能可以超过go，vert.x+kotlin应该也行
但是会略弱于vert.x+java，但是可读性会超过vert.x+java（现阶段）
其次vert.x&go不管在什么时候，都可以吊打其他任何一个同步api的系统
用异步或者协程肯定比同步快，快很多，尤其是在io bound的时候
再来，我们可以保证，用vert.x，可以把用户线程控制在很少量的几个上
具体是cpu available cores * 2
比如1core就是2个线程就够了
再来，在线程数有限的前提下，coroutine要做的事很少，就是suspend&resume
我相信go的coroutine要做的更多
木有错，所以go很有可能做得不好，所以性能比不过vert.x
说这些，都需要证据，不要没事blablabla，证据就在这里
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json
我个人认为啊，vert.x和异步，再加上coro... 阅读全帖 |
|
z****e
发帖数: 54598 | 3
净说些没用的，探讨一下高性能的架构
你上次说的cooperative scheduling的主要问题就是lock
lock多了性能就下来了，对吧？
这个问题可以通过actor model解决
而且一定要手动挡，不能自动让os去考虑resume这些问题
什么时候suspend，什么时候resume，要暴露给框架去使用
语言和os系统层面，不用管，只需要提供接口就好了
要不然actor model威力发挥不出来
现在一般是io时候，才会使用suspend，callback之后resume
然后actor model要确保跟cpu cores匹配的线程数运行
不能造一大堆线程，线程数下降了，并发修改的lock就减少了
然后要求线程之间的通信，全部是immutable的
这样lock就彻底干掉了，用户线程专心执行交给它的代码就好了
那么coroutine有一个重要作用，就是执行之后要能够suspend
我们把遇到io的api全部做成异步和suspendable的
然后在verticle中使用coroutine，这样一来，就不要求cooperative sheduling有什么
lock了
不... 阅读全帖 |
|
z****e
发帖数: 54598 | 4
vert.x过去两年大发展啊，早已今非昔比了
这两年错过vert.x的是一个巨大的损失，不是我说
准备技术输出了，然后噱头就是
比spring mvc快几十倍
生态比go好几十倍
市场买不买这个账，不知道，管他呢，反正就是宣传
至于kotlin对vert.x的促进作用，看上面讲的coroutine部分
这个中国人贡献的代码已经merge进官方库了
马上就release了，就能用了
3.5的新增功能包括
kotlin的coroutine原生支持
rxjava 2.0的升级
jdbc client的callback的简化
强烈建议马上升级
ceylon贡献给了eclipse之后，也会加入coroutine
java这个还需要时间
现在项目中，java, kotlin, groovy都有，因为idea社区版加入了scala的滋持
所以准备上scala了，至于js本来就有，但是gradle里面一般都放在resources目录下
最近搞了下ruby，感觉挺好玩的，拿ruby和另外一个中国人写的脚本到时候来做演示
展示一下这个随便选一个脚本就能用来开发项目是怎样一番光景
太有趣了
vert.x最... 阅读全帖 |
|
z****e
发帖数: 54598 | 5 java的coroutine 阿里的jvm已经做出来了
不过这也不是什么黑科技，能做出来的大把
而且不配合actor model的话
lock还是很多，性能还是上不去
只有配合了actor model，把线程数降下来
这样lock数量才会减少，而且引入immutable才会变得合理起来
否则满天飞的immutable，性能也还是上不去
但是这样要求不能写blocking code
这个只要有coroutine，书写难度就降下来很多
要不然一大堆高阶函数，哪有办法
map来map去的，很多人搞不定
coroutine之后，fp这一波热潮也差不多该到头了
最早是用来解决callback hell的方式
现在不用了，那高阶函数存在感会大幅下降
monad这些估计根本就没啥市场了
基本上跟之前预测的很像
就是知道什么是immutable，什么是1st class citizen这些
然后懂得用lambda，可以了
足够了，coroutine会接管剩下的部分
有了coroutine，就可以调用异步api，如同同步api一样
而且kotlin会在idea里面，给你加上一个绿色的小箭头
非常好玩 |
|
w***g
发帖数: 5958 | 6 有理. cooperative threading有助于降低lock contention.
但是你有没有想过, 如果OS thread lock了, 这个thread上面所有的
coroutine就全都挂起了. 我实在不愿意用coroutine这个词,
因为你们说的其实就是cooperative user-space threading.
真正的coroutine好几十年前就已经死了. 主流语言没一个支持
coroutine的. python的yield勉强算半个吧.
我上次说这个都好几年前了吧. 我现在改行做machine learning了. |
|
g****t
发帖数: 31659 | 7 Python function参数如果是mutable,不是每次调用的时候
有trick吗，例如
def f(..,x=[0])
我经常用x放上次函数被调用时候的信息。算是显式的yield。
Python 自己的yield我不用，因为它跟c实现的很多yield不太一样。
这些东西其实都是内存快照加上一些goto
: 有理. cooperative threading有助于降低lock contention.
: 但是你有没有想过, 如果OS thread lock了, 这个thread上面所有的
: coroutine就全都挂起了. 我实在不愿意用coroutine这个词,
: 因为你们说的其实就是cooperative user-space threading.
: 真正的coroutine好几十年前就已经死了. 主流语言没一个支持
: coroutine的. python的yield勉强算半个吧.
: 我上次说这个都好几年前了吧. 我现在改行做machine learning了.
|
|
z****e
发帖数: 54598 | 8
kotlin的coroutine在3.5中会加入
这个我可以跟你保证
如果没有你来找我，我给你多少伪币都行
那个pr已经merged
viet还会写一个blog介绍具体怎么使用
其实你自己加都无非那么一回事
关键的类是那个中国人写的coroutine dispatcher
主要是让coroutine run在vertx thread上就行
因为kotlin官方coroutine api支持的那几个fork&join, single thread啊这些
就少一个eventloop，用context.run on context就可以搞定了
顺便说一下，vert.x的kotlin那个主要贡献者，就是jetbrains的人
kotlin这个语言的支持，那个毛子贡献了三年 |
|
z****e
发帖数: 54598 | 9
听得懂的人自然懂
甚至是秒懂
第一个回帖就会同意我的看法
听不懂的人，死活就是不懂
还在lock上纠结
没戏
我觉得这是某些人傲慢的态度决定的
我说了中间少了一步
让他们去看，我觉得他们不会认真去研读的
包括wdong在内，其实压根就没看我在说什么
一副老子懂得比你多的傲慢态度
这样说下去就是鸡同鸭讲
没戏，放弃了，不用浪费时间了
你跟他们说，我们要的coroutine，就是一个简单的suspend&resume的功能
他们会说，这个不是coroutine，真正的coroutine是怎样怎样blablabla
至于这你妹是不是coroutine，话克，谁在乎？这不过一个定义而已
看过那个笑话吧？
老罗说，我要这个中杯
对不起先生，这个是大杯，左边这个是中杯，这个是大杯，这个是超大杯
……
我上视频吧哈
https://www.youtube.com/watch?v=ZdpiaZaZaDU |
|
z****e
发帖数: 54598 | 10
是啊，所以要求用户不能block住eventloop
这样来保证所有的用户thread都lock free
这个也是很麻烦的一件事，在工作中，很多人搞不清楚到底什么时候会block
解释半天，听不懂的很多
这里面涉及到复杂度，io这些
听得懂，工资就贵，听不懂的就便宜，这世界上没有两全的事
那要解决这个问题，那现在是这样
gradle的依赖全部控制住，不允许随便乱加第三方类库
如果要加，要review，gradle有一个build.gradle，所以定期review这个文件就好了
然后尽量用异步库，拿到异步库之后，用coroutine包装成类似同步的suspend方法
这样用起来就无压力了，这个还不会就直接火掉了
用这种方式来解决问题
os thread的lock，控制不了，这个也无能为力
只能看os自身的搞法了，但是对于要实现coroutine的jvm来说
这个实现的难度就降低很多了
coroutine是当前主流说法，只能从众 |
|
z****e
发帖数: 54598 | 11 import io.vertx.core.Context
import kotlinx.coroutines.experimental.CoroutineDispatcher
import kotlin.coroutines.experimental.CoroutineContext
open class VertxContextDispatcher(val vertxContext: Context, val vertxThread
:Thread) : CoroutineDispatcher() {
override fun dispatch(context: CoroutineContext, block: Runnable) {
if (Thread.currentThread() !== vertxThread) vertxContext.
runOnContext { _ -> block.run() }
else block.run()
}
}
关键的一个类，确保coroutine在vertx thread上运行
3.5中这... 阅读全帖 |
|
|
z****e
发帖数: 54598 | 13 coroutine可以看一下kt的解释
其实就是一个状态机
suspend之后，定期去check一下是否可以resume
这个放在eventloop里面就特别方便
因为eventloop本来就是一个无限循环的线程
每一次loop去check一下就是了
因为有这一步的消耗，所以性能会损耗3%-5%
我估计就是这么来的
但是当前java要实现这个，关键是方法内部的状态
在suspend之后，线程转去执行其他操作之后
这个状态会丢失，用reflection也解决不了这个问题
还是需要存context，如果os支持，直接wrap一层
如果不支持，则需要jvm／java自己实现
ceylon这个语言估计很快也会有coroutine了
这个feature快烂大街了 |
|
z****e
发帖数: 54598 | 14
又看了一遍，对vert.x的认识又加深了一层
对go反而没啥感觉
你说到在多核上做用户态线程是很恶心的一件事
假设是真的
那么vert.x就更加合理了
因为vert.x对比node.js，就是把原来单核的事
变成了多核的事，由multiple reactors来解决这个问题
所以等到它找到coroutine的时候
coroutine只需要考虑单核情况就可以了
就类似node.js
所以actor model越看越不可或缺，如果没有actor model
光靠语言一个来做，够呛
你说go做成了，嗯
只能说道路不同，go想做的更多
但是这样做的效果如何，目前看，觉得它做的一般
从benchmark上看，并没有表现出多少优势
https://www.techempower.com/benchmarks/#section=data-r14&hw=ph&test=json |
|
x***4
发帖数: 1815 | 15 我个人感觉：
FP和immutable data能够让相当一部分业务逻辑容易理解，也容易测试。
但是用FP写async也不比callback hell好太多，还是非常繁琐难理解。
async/await，coroutine能让你的code长得跟同步的code差不多，能让async程序白菜
化。
最后插一句，static typing，容易做refactoring，bug也小。
所以我最喜欢fp+static type+coroutine。 |
|
|
l**********n
发帖数: 8443 | 17 coroutine is more like single-thread |
|
z****e
发帖数: 54598 | 18 其实一路走来
同步转异步，lock free，减少线程数，不要乱开线程，这很重要
遇到callback hell
解决callback hell，通过promise/future方式->高阶函数
高阶函数->reactivex，感觉不方便
coroutine出现，改进写法
这么一串下来，理解起来就很容易
还是要跟着vert.x一起成长 |
|
|
|
z****e
发帖数: 54598 | 21 其实coroutine对于我们来说，只是锦上添花的作用而已
性能相比起callback和高阶函数来说，性能要牺牲个3%-5%
但是好处是可以让普通程序猿，用他习惯的方式来写代码
而不用去搞fp那一套 |
|
z****e
发帖数: 54598 | 22
ml那个东西到底怎么赚钱，business model至今无法验证
ng又跑回去开课赚钱了，这个风险太大
但是这种性能提升对于客户价值来说意义甚大
开支马上降下来，效果立竿见影
这些年异步(lambda)，callback(node.js)，coroutine(go)都在摸索
到现在这个阶段，算是一个大成了，总算是解决了这个问题
不管是性能上的提升，保证可读性这些，各方面都有了一个能够接受的答案
这是我在vert.x上用kotlin的感受，那下面就是推广了 |
|
O***b
发帖数: 104 | 23 我去看了一下 vert.x 3.5的 roadmap，好像这个版本不会加入coroutine吧
cooperative |
|
z****e
发帖数: 54598 | 24 看了下，文档已经写得差不多了，应该这两天就会release
github.com/vert-x3/vertx-lang-kotlin/blob/master/vertx-lang-kotlin-
coroutines/src/main/asciidoc/kotlin/index.adoc |
|
z****e
发帖数: 54598 | 25
immutable还是有用的，verticle之间需要immutable，用cglib做immutable object
type无所谓，用verticle封死就无所谓到底是static还是dynamic，就那点代码，随便玩
然后coroutine/async/await
实践中，对于java程序猿，没有接触过其他环境的java程序猿，纯后端出身的程序猿
我们一般建议先从groovy开始接触其他环境，一般半个小时后就能开始写了
动态类型并没有什么问题，前提是写verticle，然后元数据编程很好用
一个@immutable就能作出immutable了，都不需要自己倒腾cglib了，虽然cglib也不难
如果是以前做安卓的，则建议从kotlin开始接触其他环境
最近idea社区版支持scala啦，开始逐步接触尝试尝试
同时建议写点ruby啊什么的，来锻炼一下脚本的语法糖，蛮好玩的
目标成就：vert.x上全语言制霸 |
|
s***o
发帖数: 2191 | 26 vert.x已经把multi-core的问题解决了，再用coroutine来解决callback hell还有各种
恶心的async问题，performance还不受影响。这个组合感觉会非常不错 |
|
x***4
发帖数: 1815 | 27 vertx 3.5出来了。谁讲讲kotlin coroutine？ |
|
x***4
发帖数: 1815 | 28 vertx 3.5出来了。谁讲讲kotlin coroutine？ |
|
T********i
发帖数: 2416 | 29 还是那句话。You have to know your own shit。
自己的系统，状态转换函数都稀里糊涂，指望别人能帮你维护好，那不是扯淡么？
如果你自己能保证任何时候状态可控，你TM要coroutine有啥用？ |
|
z****e
发帖数: 54598 | 30
我们先找一个共识
就是在一个core上做
很容易，因为没有lock
对吧？这个是所有人都认可的
然后在这个基础之上，我们有两条路可以走
一种是直接上coroutine，要求coroutine解决多核环境下调度的问题
这就是go走的这条路，我相信这条路不好走
也需要“牛得不得了的人”才能搞定，很有可能
另外一条路是这样，你先放下这个问题，我们继续往前走
看看有没有其他的路，找啊找
诶，突然发现，有一条路叫做actor model
可以通过eventloop这种方式，把原来一大票线程给降下来
为什么呢？原理很简单，原先io的时候，同步api无论如何
要占用一个线程，给我等着
异步api的好处就是可以马上释放调用线程
这样我们可以复用同一个线程，然后对于我们常见的场景
也就是那些大量crud的业务场景
基本上都是io bound的场景，所以可以通过少量线程就能host住大量的请求
比如原来用tomcat，要几千个线程的线程池
现在只需要20多个就行了，甚至用1core 1g的机器，也就是2个eventloop，记住这个关
键字
以后你会经常遇到，spring都开始eventloop，spr... 阅读全帖 |
|
T********i
发帖数: 2416 | 31 coroutine和iterator根本就是两个概念。coroutine有自己的stack，yield以后也要有
context switch，iterator不一定。
基于coroutine可以有multi-task和scheduler。因此coroutine yield以后，可以直接
回到scheduler，执行权落在那一行程序是由scheduler决定，不一定是确定的。
因此coroutine和thread很像。但是就是yield的含义不一样。我不确定std::thread实
现coroutine是不是一个好主意？因为为了能够做到兼容，因为thread多任务不需要
yield也能保证响应，但是coroutine必须yield，因此为了保证兼容性长任务要插入
yield才能保证响应，但是会带来额外的负担。
goroutine这种就是coroutine，context switch只需要切换stack和register，不需要
flush cache，switch TLB，security check，这些都是微秒级别的操作。而且内置
scheduler
，还要在I/O函数外面包上w... 阅读全帖 |
|
w***g
发帖数: 5958 | 32 coroutine和monitor是两个基本上被实践抛弃了的概念。python的
yield其实是标准的coroutine，但是一般讲python的资料都会把它
叫做iterator或者generator。现在还在提coroutine的，一般都是
哗众取宠混淆视听。
如何区别coroutine和thread的一个标准就是：coroutine的yield
返回后，执行权落在那一行程序是确定的，由程序的
逻辑决定。thread yield/preempt了以后，执行权落在那一行程序是
不确定的，由thread scheduler决定的。即使是cooperative thread
跑在一个CPU上，执行权落哪儿也是不确定的。
goroutine就是一种light-weighted thread，不是coroutine。
wikipedia上那篇coroutine也是概念非常混淆乱讲一通。其实只要
程序写对了，抠概念屁用没有。我书读太多脑子有点坏掉了。 |
|
z****e
发帖数: 54598 | 33 lambda是java8的东西
java8第一个版本在2014年
实际上在java之前，scala先做出了jvm上的lambda
所以有了akka，先于java的vert.x之前好多年做出来
然后java有了lambda，消化吸收了node.js和akka之后才有了vert.x
有了vert.x我们才能把线程数降下来，减少lock
从而对coroutine的要求就简化成了node.js对于coroutine那种的要求
不需要考虑多核，不需要考虑lock，actor model解决了这个问题
所以这个时候coroutine只要很简单的能够暂停，能够恢复
就够用了，这样就能解决callback带来的恶心的书写问题
而在此之前，因为lock满天飞，所以即便能够暂停，能够恢复
也很难提升性能，但是当前提改变了
要求降低了之后，coroutine的作用就体现出来了
所以这个时候一堆语言才开始搞coroutine
这里有一个lambda和actor model成熟的前提
如果线程数降不下来，lock一大堆，用不用coroutine都一样
反正性能就是上不去，线程数降下来，节省一个线程，内存stac... 阅读全帖 |
|
z****e
发帖数: 54598 | 34
Function0
停停停
你没有用过vert.x
所以鸡同鸭讲
我给你一个建议，去看看vert.x的设计
然后再来谈
死锁？
都lock free了，死锁什么哟？
都用这么久，遇到过搞不定高阶函数的
还真没遇到过死锁的
vert.x一直就是reactive programming
正是在实践中遇到了问题
所以我们才会寻找答案
而现在说的coroutine
正是我们找到的答案
之前搞reactive programming
最大的麻烦就是普通程序猿掌握不了高阶函数的使用
map, flatmap，副作用，绕晕了，搞不定我去
后来情愿换成kotlin，coroutine白菜化异步api
然后就ok啦
还是那句话，你们没有经验，看不懂
我当然知道高阶函数，reactive是一种解决方案
但是很麻烦，一般程序猿搞不定
思维上的改造不是那么容易的
这就是为什么一大堆语言都在搞coroutine/async/await的主因
fp那些，主流不感兴趣，因为搞不懂嘛
没有coroutine之前，我们推广reactive，多恶心你知道嘛？
一说副作用，无状态函数，fp下面一大堆人在睡觉，哈欠连天
这... 阅读全帖 |
|
w***g
发帖数: 5958 | 35 std::thread对实现没有明确要求，理论上说可以是用户态线程也可以是操统线程。
可以是preemptive也可以是cooperative。比如说把std::thread移植回windows 3.1，
就会出现cooperative的操统线程。C++的yield是为了支持cooperative thread，
跟coroutine没有直接的关系。
coroutine是语言概念，基本上相当于(python的)"yield"关键字。thread是操作系统概
念，
基本上就是share memory space的process。虽然对于没有yield关键字的语言，
可以用类似cooperative user-space thread的方式实现。但是在编程模型上
的用法是有区别的。一个例子就是thread A上面跑了coroutine A1和A2，
thread B上跑了coroutine B1和B2。其中A1和B2在某一步用mutex进行了同步。
那么这个mutex同步的是线程A和B。Coroutine本身是没有同步概念的。
thread |
|
z****e
发帖数: 54598 | 36
你还是没有看懂人家说的coroutine的目的啊
coroutine是语法糖
主要目的是从高阶函数中解放程序猿
因为高阶函数太多人搞不明白
所以用coroutine或者叫简化的coroutine来解放程序猿
把我的例子认真看一遍
看看coroutine是怎么把程序猿从高阶函数中解放出来的
这个才是目的
说了半天，你们根本就不懂其他人在干嘛
老是用底层那些东西来思考问题
少了一层东西，然后就是死活理解不了
累不累？感觉鸡同鸭讲了 |
|
w***g
发帖数: 5958 | 37 coroutine主要是有语法上的好处，跟性能没关系。比如下面这个语法就很漂亮。
def fab(max):
n, a, b = 0, 0, 1
while n < max:
yield b # 不是线程调度那个yield
a, b = b, a + b
n = n + 1
for n in fab(5):
print n
C/C++要实现coroutine也是用类似context的方法，以至于有一些人就直接把
coroutine和context等同了，光从性能上来考虑问题，忘了语法上的好处。
再说C/C++没有语法糖，就是用coroutine也写不出漂亮的程序。
managed
operating
. |
|
z****e
发帖数: 54598 | 38 coroutine之后，所有的语言都在跟fp对着干
高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
immutable能搞懂就谢天谢地了
最简单的future和promise那种写法已经有很多人搞不定了
就是用java一样看挂掉很多人
最后还是coroutine，async，await这种同步的，oop的写法会prevail
其实能把io的同步转异步解决，这事就解决了99%
榨取机器性能的目的就已经达到了
fp没戏，当初记得谁说过
fp这一波，也就是知道一下
什么是lambda，什么是1st class citizen，什么是immutable
就行了，剩下的monad，currying这些，不用纠结
果不其然，没有coroutine，为了对付callback hell，木有办法，只能上高阶函数
有了coroutine，那就不需要了，原来同步怎么写就怎么写
可以开开心心用循环而不是诡异的递归了
否则每次loop都要写成递归，好诡异啊
一大堆人问，callback里面怎么return啊？
其实脚本这种东西举了个fp的大旗往前冲本身就是很诡异的一件事
写个脚本天... 阅读全帖 |
|
z****e
发帖数: 54598 | 39
给你看一下对比
当前暂没有coroutine的java的高阶函数的写法
Future.>future(f ->
vertx.eventBus().send("address1", "message", f)
).compose((msg) ->
Future.>future(f ->
vertx.eventBus().send("address2", msg.body(), f)
)
).compose((msg) ->
Future.>future(f ->
vertx.eventBus().send("address3", msg.body(), f)
)
).setHandler((res) -> {
if (res.failed()) {
//deal with exception
return;
}
//deal with the result
});
嗯，不是太好看懂，这里有几个语法糖和简写，当前没有corouti... 阅读全帖 |
|
z****e
发帖数: 54598 | 40 你要看什么？
不用等5年
现在已经有了
早就有了
http://vertx.io/docs/vertx-sync/java/
https://github.com/puniverse/quasar
你说java做不出来？现有的东西出不来？
现在一大票语言都开始async／await，coroutine什么都出来了
你想等5年之后？等什么？等这些语言一个个做出来嘛？
现在已经有好几个了，比如kotlin，你是说这个东西不存在？
说了，不是你想的那种coroutine，你被wdong绕进去了
wdong说的那种coroutine不是我们需要的coroutine或者说不是那么复杂的东西
我们只需要其中一小部分，就能满足要求了
用工具的目的是用来解决问题的，不是用来探索真理的
你要探索宇宙的真相，大可以去物理学上咕哝上半天
反正买买提每次讨论物理都很热闹
我们要处理的是怎么榨取机器性能，同时保证可读性不要下降 |
|
|
g****t
发帖数: 31659 | 42 java 的coroutine多半是没戏的
你找个用c,c 写过硬件相关code的问问就明白了
或者放5年看看
Java应该早点搞定多维数组
本身是往上走的好语言往下走管毛用
: coroutine之后，所有的语言都在跟fp对着干
: 高阶函数太难用了，map，flatmap，reduce之类的没几个能搞懂的
: immutable能搞懂就谢天谢地了
: 最简单的future和promise那种写法已经有很多人搞不定了
: 就是用java一样看挂掉很多人
: 最后还是coroutine，async，await这种同步的，oop的写法会prevail
: 其实能把io的同步转异步解决，这事就解决了99%
: 榨取机器性能的目的就已经达到了
: fp没戏，当初记得谁说过
: fp这一波，也就是知道一下
|
|
|
s********k
发帖数: 6180 | 44 python还是做不好那种CPU bound的Concurrency， 如果只是IO bound的gevent和
twisted都不错，或者可以自己实现一个coroutine的简单架构，我原来做过一个
coroutine的自己轮子，很方面。
关于GIL的问题参见david beasley的PPT，讲得很好 |
|
p**o
发帖数: 3409 | 45 Here is a good tutorial of using asyncio / Tulip in Python 3.4
Fast scraping in python with asyncio
http://compiletoi.net/fast-scraping-in-python-with-asyncio.html
PS: Glyph(& perhaps also Guido)'s opinion on different async models:
straight callbacks (Twisted IProtocol),
managed callbacks (Twisted Deferred),
explicit coroutines (Tulip / yield from: the one to be standardized),
implicit coroutines (eventlet, gevent)
They really strongly oppose any implicit monkey-pactch/hack
https://glyph.twiste... 阅读全帖 |
|
L***s
发帖数: 1148 | 46 我不熟js。略懂Python。
Python的coroutines (`yield` / enhanced generators)
和async io (`yield from`) 也是都callbacks的上层封装抽象，
底下都是裸体callbacks实现的。上下层同时暴露，虽然鼓励用上层封装。
js若要提供上层抽象估计也是类似思路，在现有的callbacks基础上封装。
coroutines和callbacks不是对立的，只是抽象层次不同，前者可用后者实现。 |
|
d******e
发帖数: 2265 | 47 看了一下go，感觉就是python的gevent或者其他coroutine方法。本质上，generator/
coroutine也可以组成数据处理的 pipeline.而且比scala的函数风格好读多了。python
的问题是不稳定。量上去👮会各种网络错误，总是要加retry.
简单倒是简单。不知道轮子足够多。第二还得花时间学啊。
另外，异步操作的combination怎么做？需要每次都join一下嘛？ |
|
d****i
发帖数: 4809 | 48 发现一片很好的文章，解释了thread, coroutine, fiber之间的联系和区别，结论是
Use thread for sure if you can, 哈哈。
http://stackoverflow.com/questions/16765736/why-doesnt-linux-us
Coroutines, fibers and their ilk are thread-like execution contexts managed
by programming language runtimes or libraries, rather than by the operating
system, which regards them to be in one thread. They are of limited use;
nobody in their right mind uses such hacks when real threads are available. |
|
w***x
发帖数: 105 | 49 感觉coroutine在某些特殊情况下，能避免使用multi-thread。。。
有些好奇，比如coroutine的r/w queue有无标准实现？多个reader,一个writer，贴个
代码看看。。。 |
|
|
