n*3
2 楼
对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
样，头脑简单。这样不妙啊。
求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
准。
样，头脑简单。这样不妙啊。
求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
准。
T*i
3 楼
很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
器架构，都给予支持和保障。
async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
这些还是忽略真正的多核并发的情况。
器架构，都给予支持和保障。
async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
这些还是忽略真正的多核并发的情况。
s*u
4 楼
2-4 weeks.
p*e
5 楼
我觉得最好be yourself
在这种情况下产生的感情才真实容易持久
否则太刻意也许只能短期解决所谓问题
如果这个不work，说明真的不合适，也没必要强求
总会有合适的
【在 n*******3 的大作中提到】
: 对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
: 样，头脑简单。这样不妙啊。
: 求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
: 准。
在这种情况下产生的感情才真实容易持久
否则太刻意也许只能短期解决所谓问题
如果这个不work，说明真的不合适，也没必要强求
总会有合适的
【在 n*******3 的大作中提到】
: 对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
: 样，头脑简单。这样不妙啊。
: 求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
: 准。
w*g
6 楼
async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
l*o
7 楼
楼上正解
但是你一定要上
那么...精神上的姐弟恋要看你们是否都吃得消
但是你一定要上
那么...精神上的姐弟恋要看你们是否都吃得消
T*x
8 楼
reinvent thread？
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
d*k
9 楼
现在她肯定还没喜欢上你吧，那你成熟点试试。
【在 n*******3 的大作中提到】
: 对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
: 样，头脑简单。这样不妙啊。
: 求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
: 准。
【在 n*******3 的大作中提到】
: 对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
: 样，头脑简单。这样不妙啊。
: 求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
: 准。
T*i
10 楼
不是thread，是coroutine。
而且，先天不足，根本不可能达到coroutine那个高度。
凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
毕业生，技术路线走偏了。
能流行起来，只能说这个世界太奇葩。
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
而且，先天不足，根本不可能达到coroutine那个高度。
凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
毕业生，技术路线走偏了。
能流行起来，只能说这个世界太奇葩。
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
S*9
11 楼
工作两年能成熟复杂成什么样。这样的你都搞不定，还是算了。要不你给举个例。
【在 n*******3 的大作中提到】
: 对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
: 样，头脑简单。这样不妙啊。
: 求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
: 准。
【在 n*******3 的大作中提到】
: 对方女生工作了两年，聊天聊了三次。每次都发现思维缜密，很理性。但是我却很学生
: 样，头脑简单。这样不妙啊。
: 求大哥大姐指点迷津。是不是我也要表现的成熟，稳重一点，这样才符合职业女性的标
: 准。
g*t
12 楼
容易懂。写起来容易。这也是个很大的优点。
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者
属于半
吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者
属于半
吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
n*3
13 楼
每次都很有礼貌 说你好 说话很formal。
相反我很随便，像和很熟悉的朋友一样说话，一下露怯了。
相反我很随便，像和很熟悉的朋友一样说话，一下露怯了。
T*i
14 楼
coroutine更容易懂。写起来更容易。
【在 g****t 的大作中提到】
: 容易懂。写起来容易。这也是个很大的优点。
:
:
: 不是thread，是coroutine。
:
: 而且，先天不足，根本不可能达到coroutine那个高度。
:
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者
: 属于半
: 吊子CS
:
: 毕业生，技术路线走偏了。
:
: 能流行起来，只能说这个世界太奇葩。
:
【在 g****t 的大作中提到】
: 容易懂。写起来容易。这也是个很大的优点。
:
:
: 不是thread，是coroutine。
:
: 而且，先天不足，根本不可能达到coroutine那个高度。
:
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者
: 属于半
: 吊子CS
:
: 毕业生，技术路线走偏了。
:
: 能流行起来，只能说这个世界太奇葩。
:
d*r
15 楼
一棒子打晕~~~
m*u
16 楼
回过头来看看，其实除了基本教科书的那点东西，其它都是扯淡。
但马工的特点是，不让他们扯淡，不舒服啊。
但马工的特点是，不让他们扯淡，不舒服啊。
g*t
17 楼
但go這種出現的晚啊。go寫起來難度和python差不多。
假如早出現一些時間，也許就沒python什麼事了
: coroutine更容易懂。写起来更容易。
【在 T********i 的大作中提到】
: coroutine更容易懂。写起来更容易。
假如早出現一些時間，也許就沒python什麼事了
: coroutine更容易懂。写起来更容易。
【在 T********i 的大作中提到】
: coroutine更容易懂。写起来更容易。
w*g
18 楼
CS里面，system和language是两个非常独立的分支。搞language的人，有的要
写编译器做优化，倒是懂system，但是system的人对language的理解还停留
在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
而没上升到科学的层次。
这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
CS
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
写编译器做优化，倒是懂system，但是system的人对language的理解还停留
在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
而没上升到科学的层次。
这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
CS
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
T*i
19 楼
说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。甚至是
凭空无中生有编译出system来。
比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine出来，
也是可以的。代价也不高。但是貌似从来没人做过。
从这点来看，go确实有意无意地填补了一项空白。
【在 w***g 的大作中提到】
: CS里面，system和language是两个非常独立的分支。搞language的人，有的要
: 写编译器做优化，倒是懂system，但是system的人对language的理解还停留
: 在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
:
: CS
凭空无中生有编译出system来。
比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine出来，
也是可以的。代价也不高。但是貌似从来没人做过。
从这点来看，go确实有意无意地填补了一项空白。
【在 w***g 的大作中提到】
: CS里面，system和language是两个非常独立的分支。搞language的人，有的要
: 写编译器做优化，倒是懂system，但是system的人对language的理解还停留
: 在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
:
: CS
g*t
20 楼
用c做goroutine,做了又没人推广，又没有收入，那不是白做.
我以前的公司，好多老师傅
老师傅写几个while死循环，加上几行汇编写成的yield安稳混饭十几年。
: 说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。
甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine
出来，
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看，go确实有意无意地填补了一项空白。
【在 T********i 的大作中提到】
: 说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine出来，
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看，go确实有意无意地填补了一项空白。
我以前的公司，好多老师傅
老师傅写几个while死循环，加上几行汇编写成的yield安稳混饭十几年。
: 说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。
甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine
出来，
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看，go确实有意无意地填补了一项空白。
【在 T********i 的大作中提到】
: 说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine出来，
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看，go确实有意无意地填补了一项空白。
g*t
21 楼
外行人懂应用，市场上转一圈，带着用户回过头来消灭内行人。
: CS里面，system和language是两个非常独立的分支。搞language的人，有
的要
: 写编译器做优化，倒是懂system，但是system的人对language的理解还停留
: 在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
: CS
【在 w***g 的大作中提到】
: CS里面，system和language是两个非常独立的分支。搞language的人，有的要
: 写编译器做优化，倒是懂system，但是system的人对language的理解还停留
: 在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
:
: CS
: CS里面，system和language是两个非常独立的分支。搞language的人，有
的要
: 写编译器做优化，倒是懂system，但是system的人对language的理解还停留
: 在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
: CS
【在 w***g 的大作中提到】
: CS里面，system和language是两个非常独立的分支。搞language的人，有的要
: 写编译器做优化，倒是懂system，但是system的人对language的理解还停留
: 在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
:
: CS
n*t
22 楼
async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能這麼去處理。
至於說現在很多人知道的那個"async",你也知道，面向對像這東西有用沒？我覺得是有
的，
但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的結構，但是人
群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子，
either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
至於說現在很多人知道的那個"async",你也知道，面向對像這東西有用沒？我覺得是有
的，
但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的結構，但是人
群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子，
either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
g*t
23 楼
对的。面向机器多一些的语言另外还有一个众口难调的问题。所以面向人多一些的语言
，basic, perl, python, js 这条线也会一直有自己的发展。
就是因为轮子更加容易使用中。
: async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能
這麼去
處理。
: 至於說現在很多人知道的那個"async",你也知道，面向對像這
東西有用沒？我覺
得是有
: 的，
: 但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
: 我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的
結構，
但是人
: 群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造
出的輪
子，
: either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
【在 n******t 的大作中提到】
: async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能這麼去處理。
: 至於說現在很多人知道的那個"async",你也知道，面向對像這東西有用沒？我覺得是有
: 的，
: 但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
: 我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的結構，但是人
: 群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子，
: either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
，basic, perl, python, js 这条线也会一直有自己的发展。
就是因为轮子更加容易使用中。
: async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能
這麼去
處理。
: 至於說現在很多人知道的那個"async",你也知道，面向對像這
東西有用沒？我覺
得是有
: 的，
: 但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
: 我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的
結構，
但是人
: 群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造
出的輪
子，
: either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
【在 n******t 的大作中提到】
: async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能這麼去處理。
: 至於說現在很多人知道的那個"async",你也知道，面向對像這東西有用沒？我覺得是有
: 的，
: 但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
: 我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的結構，但是人
: 群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子，
: either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
n*g
24 楼
在一个系统里，线程的数量有限。
在互联网应用中，如果因为等待如I/O而占用线程会限制了单机最大并发用户数。
async是在挂起等待时线程可以被重用。因此去除了一个瓶颈。
【在 T*******x 的大作中提到】
: reinvent thread？
在互联网应用中，如果因为等待如I/O而占用线程会限制了单机最大并发用户数。
async是在挂起等待时线程可以被重用。因此去除了一个瓶颈。
【在 T*******x 的大作中提到】
: reinvent thread？
n*g
25 楼
https://zhuanlan.zhihu.com/p/31803596
如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程，在互
联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源，
完全不实用。
【在 T*******x 的大作中提到】
: reinvent thread？
如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程，在互
联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源，
完全不实用。
【在 T*******x 的大作中提到】
: reinvent thread？
g*t
26 楼
你这个说的是并发问题。这个问题好几年前本版似乎充分讨论过了。老师傅也容易找。
我希望有多线程主要是要并行多核数值计算。
: https://zhuanlan.zhihu.com/p/31803596
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程
，在互
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用
资源，
: 完全不实用。
【在 n********g 的大作中提到】
: https://zhuanlan.zhihu.com/p/31803596
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程，在互
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源，
: 完全不实用。
我希望有多线程主要是要并行多核数值计算。
: https://zhuanlan.zhihu.com/p/31803596
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程
，在互
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用
资源，
: 完全不实用。
【在 n********g 的大作中提到】
: https://zhuanlan.zhihu.com/p/31803596
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程，在互
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源，
: 完全不实用。
x*u
27 楼
大哥，看看async/await的定义先
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
p*u
28 楼
programming languages有很多种，focus也不同。C/Golang是为了system programming
，Scheme这类的functional language则不适，不可一概而论。
【在 T********i 的大作中提到】
: 说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine出来，
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看，go确实有意无意地填补了一项空白。
，Scheme这类的functional language则不适，不可一概而论。
【在 T********i 的大作中提到】
: 说反了吧？搞language的，都要做bare metal，编译的代码要没system也能用。甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C，把所有的system call都wrap一遍，做个coroutine出来，
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看，go确实有意无意地填补了一项空白。
s*k
29 楼
async 和thread两回事把，一个是实现手段，一个是设计理念。thread 可以做
coroutine这样的，也可以做premptive这样的。
CS
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
coroutine这样的，也可以做premptive这样的。
CS
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
n*g
30 楼
我说的是为啥要/啥时候用async。
至于可能滥用async导致不应有的复杂性这锅不应该由async背。
CPU是瓶颈的并行数值计算无疑不应该用async。
【在 g****t 的大作中提到】
: 你这个说的是并发问题。这个问题好几年前本版似乎充分讨论过了。老师傅也容易找。
: 我希望有多线程主要是要并行多核数值计算。
:
:
: https://zhuanlan.zhihu.com/p/31803596
:
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程
: ，在互
:
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用
: 资源，
:
: 完全不实用。
:
至于可能滥用async导致不应有的复杂性这锅不应该由async背。
CPU是瓶颈的并行数值计算无疑不应该用async。
【在 g****t 的大作中提到】
: 你这个说的是并发问题。这个问题好几年前本版似乎充分讨论过了。老师傅也容易找。
: 我希望有多线程主要是要并行多核数值计算。
:
:
: https://zhuanlan.zhihu.com/p/31803596
:
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程
: ，在互
:
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用
: 资源，
:
: 完全不实用。
:
N*n
31 楼
此言差矣。ASYNC的最大好处就是提高效率。一组人去医院验血。护士先
抽血，然后再去验。ASYNC方式就是一个人抽完之后就离开抽血窗口到一
边去等结果，这样护士可以抽下一个人的血。SYNC方式就是抽完血的那位
非占着抽血窗口不走，直到后台验血结果出来了才离开，结果后面要抽血
的全卡住。显然ASYNC方式更合理。
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
m*n
32 楼
go在语法上是尽量去抄python
我现在搞项目，就是python+go
【在 g****t 的大作中提到】
: 但go這種出現的晚啊。go寫起來難度和python差不多。
: 假如早出現一些時間，也許就沒python什麼事了
:
:
: coroutine更容易懂。写起来更容易。
:
我现在搞项目，就是python+go
【在 g****t 的大作中提到】
: 但go這種出現的晚啊。go寫起來難度和python差不多。
: 假如早出現一些時間，也許就沒python什麼事了
:
:
: coroutine更容易懂。写起来更容易。
:
N*n
33 楼
async的卖点就在于non-blocking I/O。这个在并发系统里太重要了，所以
才流行。不明白为啥有人要反对。
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
n*g
34 楼
它软的膏药。
有更好的办法和架构。
【在 N********n 的大作中提到】
:
: async的卖点就在于non-blocking I/O。这个在并发系统里太重要了，所以
: 才流行。不明白为啥有人要反对。
有更好的办法和架构。
【在 N********n 的大作中提到】
:
: async的卖点就在于non-blocking I/O。这个在并发系统里太重要了，所以
: 才流行。不明白为啥有人要反对。
h*e
35 楼
你还是应该去补补课。
【在 N********n 的大作中提到】
:
: async的卖点就在于non-blocking I/O。这个在并发系统里太重要了，所以
: 才流行。不明白为啥有人要反对。
【在 N********n 的大作中提到】
:
: async的卖点就在于non-blocking I/O。这个在并发系统里太重要了，所以
: 才流行。不明白为啥有人要反对。
N*n
36 楼
这年头没听说有NON-BLOCKING的ASYNC模式不用，非要用BLOCKING的SYNC。
【在 h****e 的大作中提到】
: 你还是应该去补补课。
a9
37 楼
async和阻塞两码事，async只是个语法糖罢了
【在 N********n 的大作中提到】
:
: 这年头没听说有NON-BLOCKING的ASYNC模式不用，非要用BLOCKING的SYNC。
【在 N********n 的大作中提到】
:
: 这年头没听说有NON-BLOCKING的ASYNC模式不用，非要用BLOCKING的SYNC。
N*n
38 楼
async就是用来绕开阻塞干扰的。CALLEE那边阻塞不代表你CALLER这边也一起背
锅跟着阻塞。
【在 a9 的大作中提到】
: async和阻塞两码事，async只是个语法糖罢了
g*t
39 楼
两个死循环互相goto的话。可以在脑子里去掉callee和caller的概念。
我想前面好几位的意思是，非阻塞不一定需要async await那样处理。
例如你也可以自己写一个处理这类问题。例如把jump back forth所需附带的上下文包
装成函数的call。
: async就是用来绕开阻塞干扰的。CALLEE那边阻塞不代表你CALLER这边也
一起背
: 锅跟着阻塞。
【在 N********n 的大作中提到】
:
: async就是用来绕开阻塞干扰的。CALLEE那边阻塞不代表你CALLER这边也一起背
: 锅跟着阻塞。
我想前面好几位的意思是，非阻塞不一定需要async await那样处理。
例如你也可以自己写一个处理这类问题。例如把jump back forth所需附带的上下文包
装成函数的call。
: async就是用来绕开阻塞干扰的。CALLEE那边阻塞不代表你CALLER这边也
一起背
: 锅跟着阻塞。
【在 N********n 的大作中提到】
:
: async就是用来绕开阻塞干扰的。CALLEE那边阻塞不代表你CALLER这边也一起背
: 锅跟着阻塞。
T*x
40 楼
这也是我的印象。但是大牛批了，我也不敢确定。
【在 n********g 的大作中提到】
: https://zhuanlan.zhihu.com/p/31803596
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程，在互
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源，
: 完全不实用。
【在 n********g 的大作中提到】
: https://zhuanlan.zhihu.com/p/31803596
: 如这个，无论是1024线程/进程（网络服务占用一个进程）还是65536线程/进程，在互
: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源，
: 完全不实用。
g*t
41 楼
非阻塞各种思路都可以处理。例如用下面的c的macro.
看上去啥都能干。保持开放心态就好。回到之前我个人的感觉。假如没有靠谱的多线程
支持，即使I/O bound问题也会有不少麻烦。更别说现在各种统计和机器学习都是往偏
CPU,GPU走。
__LINE__
This macro expands to the current input line number, in the form of a
decimal integer constant. While we call it a predefined macro, it’s a
pretty strange macro, since its “definition” changes with each new line of
source code.
: 这也是我的印象。但是大牛批了，我也不敢确定。
【在 T*******x 的大作中提到】
: 这也是我的印象。但是大牛批了，我也不敢确定。
看上去啥都能干。保持开放心态就好。回到之前我个人的感觉。假如没有靠谱的多线程
支持，即使I/O bound问题也会有不少麻烦。更别说现在各种统计和机器学习都是往偏
CPU,GPU走。
__LINE__
This macro expands to the current input line number, in the form of a
decimal integer constant. While we call it a predefined macro, it’s a
pretty strange macro, since its “definition” changes with each new line of
source code.
: 这也是我的印象。但是大牛批了，我也不敢确定。
【在 T*******x 的大作中提到】
: 这也是我的印象。但是大牛批了，我也不敢确定。
N*n
42 楼
楼上niuheliang已经给了很清楚的解释了。在互联网SERVER上THREADS数量有
限，如果THREAD被I/O阻塞那么系统效率就完了。这个REQUEST堵，那个也堵。
三下两下THREAD POOL就用光了。所以互联网的代码才强调要用ASYNC。有没有
ASYNC效率能差一个MAGNITUDE甚至更多，绝不是简单一个语法糖而已。
发信人: niuheliang (别问我是谁), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan 7 00:01:29 2019, 美东)
在一个系统里，线程的数量有限。
在互联网应用中，如果因为等待如I/O而占用线程会限制了单机最大并发用户数。
async是在挂起等待时线程可以被重用。因此去除了一个瓶颈。
【在 g****t 的大作中提到】
: 两个死循环互相goto的话。可以在脑子里去掉callee和caller的概念。
: 我想前面好几位的意思是，非阻塞不一定需要async await那样处理。
: 例如你也可以自己写一个处理这类问题。例如把jump back forth所需附带的上下文包
: 装成函数的call。
:
:
: async就是用来绕开阻塞干扰的。CALLEE那边阻塞不代表你CALLER这边也
: 一起背
:
: 锅跟着阻塞。
:
g*t
43 楼
Goroutines 类似的东西在其他语言里也有啊。
不一定async／await才能IO解决阻塞问题。
你也可以自己写一个所谓的lightweightthread。
取个名字叫做TaskLeaf
为什么要在async，await一棵树上挂着才可以解决IO阻塞？
我感觉这不符合逻辑。也不符合现实情况。
【在 N********n 的大作中提到】
:
: 楼上niuheliang已经给了很清楚的解释了。在互联网SERVER上THREADS数量有
: 限，如果THREAD被I/O阻塞那么系统效率就完了。这个REQUEST堵，那个也堵。
: 三下两下THREAD POOL就用光了。所以互联网的代码才强调要用ASYNC。有没有
: ASYNC效率能差一个MAGNITUDE甚至更多，绝不是简单一个语法糖而已。
: 发信人: niuheliang (别问我是谁), 信区: Programming
: 标 题: Re: async那个架构其实很容易证明会增加复杂度的
: 发信站: BBS 未名空间站 (Mon Jan 7 00:01:29 2019, 美东)
: 在一个系统里，线程的数量有限。
: 在互联网应用中，如果因为等待如I/O而占用线程会限制了单机最大并发用户数。
不一定async／await才能IO解决阻塞问题。
你也可以自己写一个所谓的lightweightthread。
取个名字叫做TaskLeaf
为什么要在async，await一棵树上挂着才可以解决IO阻塞？
我感觉这不符合逻辑。也不符合现实情况。
【在 N********n 的大作中提到】
:
: 楼上niuheliang已经给了很清楚的解释了。在互联网SERVER上THREADS数量有
: 限，如果THREAD被I/O阻塞那么系统效率就完了。这个REQUEST堵，那个也堵。
: 三下两下THREAD POOL就用光了。所以互联网的代码才强调要用ASYNC。有没有
: ASYNC效率能差一个MAGNITUDE甚至更多，绝不是简单一个语法糖而已。
: 发信人: niuheliang (别问我是谁), 信区: Programming
: 标 题: Re: async那个架构其实很容易证明会增加复杂度的
: 发信站: BBS 未名空间站 (Mon Jan 7 00:01:29 2019, 美东)
: 在一个系统里，线程的数量有限。
: 在互联网应用中，如果因为等待如I/O而占用线程会限制了单机最大并发用户数。
N*n
44 楼
总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
/AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
【在 g****t 的大作中提到】
: Goroutines 类似的东西在其他语言里也有啊。
: 不一定async／await才能IO解决阻塞问题。
: 你也可以自己写一个所谓的lightweightthread。
: 取个名字叫做TaskLeaf
: 为什么要在async，await一棵树上挂着才可以解决IO阻塞？
: 我感觉这不符合逻辑。也不符合现实情况。
C*l
45 楼
你这个不是相当于自己手写async
【在 g****t 的大作中提到】
: Goroutines 类似的东西在其他语言里也有啊。
: 不一定async／await才能IO解决阻塞问题。
: 你也可以自己写一个所谓的lightweightthread。
: 取个名字叫做TaskLeaf
: 为什么要在async，await一棵树上挂着才可以解决IO阻塞？
: 我感觉这不符合逻辑。也不符合现实情况。
【在 g****t 的大作中提到】
: Goroutines 类似的东西在其他语言里也有啊。
: 不一定async／await才能IO解决阻塞问题。
: 你也可以自己写一个所谓的lightweightthread。
: 取个名字叫做TaskLeaf
: 为什么要在async，await一棵树上挂着才可以解决IO阻塞？
: 我感觉这不符合逻辑。也不符合现实情况。
p*u
46 楼
non-blocking只是讲一个module，async是讲两个module之间，科普完毕。
ASYNC
【在 N********n 的大作中提到】
:
: 总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
: /AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
: SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
: 其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
: CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
ASYNC
【在 N********n 的大作中提到】
:
: 总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
: /AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
: SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
: 其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
: CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
g*t
47 楼
网站并发问题适合用async。不等于IO bound阻塞只有
async 一个办法。
你说不能sync, 啥叫sync ?
一个
while (1)
写下来算sync吗？
但我在里面可以goto .
这不就不阻塞了。
这玩意没必要那么复杂。假如你认为电商的现实是
Async-await用的多. 那我们就尊重这个现实.
但你要往普遍的IO阻塞推广。那理论基础要清晰明确才可以。我觉得你论据不足啊。你
想想多少种goto可以绕开容易阻塞的那一段。然后把goto转化成结构化编程风格，或者
oo风格，或者functional 风格。这要有多少花样。
我的判断是async-await是其中的一种。除了在一些场合的实用价值，没什么需要特别
强调的。
: 总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，
至于是
用ASYNC
: /AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
: SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
: 其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都
是ASYNC
: CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
【在 N********n 的大作中提到】
:
: 总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
: /AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
: SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
: 其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
: CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
async 一个办法。
你说不能sync, 啥叫sync ?
一个
while (1)
写下来算sync吗？
但我在里面可以goto .
这不就不阻塞了。
这玩意没必要那么复杂。假如你认为电商的现实是
Async-await用的多. 那我们就尊重这个现实.
但你要往普遍的IO阻塞推广。那理论基础要清晰明确才可以。我觉得你论据不足啊。你
想想多少种goto可以绕开容易阻塞的那一段。然后把goto转化成结构化编程风格，或者
oo风格，或者functional 风格。这要有多少花样。
我的判断是async-await是其中的一种。除了在一些场合的实用价值，没什么需要特别
强调的。
: 总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，
至于是
用ASYNC
: /AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
: SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
: 其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都
是ASYNC
: CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
【在 N********n 的大作中提到】
:
: 总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
: /AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
: SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
: 其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
: CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
g*t
48 楼
这类讨论。所有讨论者能接受的一个共同ground, 我认为是goto, 因为不管什么人讲自
己避开阻塞，画图就是goto的图啊。
这不就都是propose一个方法消除goto嘛！
: 你这个不是相当于自己手写async
【在 C*****l 的大作中提到】
: 你这个不是相当于自己手写async
己避开阻塞，画图就是goto的图啊。
这不就都是propose一个方法消除goto嘛！
: 你这个不是相当于自己手写async
【在 C*****l 的大作中提到】
: 你这个不是相当于自己手写async
N*n
49 楼
我的原文就在楼上。我明白的指出ASYNC是为了NON-BLOCKING I/O。既然都I/O
了，那当然不止一个module了，最典型的例子就是CLIENT/SERVER之间的交互
吗。你这里还在用单机思维去套。这个讨论一路看下来除了NIUHELIANG之外，
很多人连ASYNC的常见用途都不知道。
【在 p*u 的大作中提到】
: non-blocking只是讲一个module，async是讲两个module之间，科普完毕。
:
: ASYNC
p*u
50 楼
其实事实刚好相反，是你和niuheliang根本不懂得software engineering中non-
blocking和async两个concepts之间的区别，成天拿网站IO胡搅蛮缠。
【在 N********n 的大作中提到】
:
: 我的原文就在楼上。我明白的指出ASYNC是为了NON-BLOCKING I/O。既然都I/O
: 了，那当然不止一个module了，最典型的例子就是CLIENT/SERVER之间的交互
: 吗。你这里还在用单机思维去套。这个讨论一路看下来除了NIUHELIANG之外，
: 很多人连ASYNC的常见用途都不知道。
blocking和async两个concepts之间的区别，成天拿网站IO胡搅蛮缠。
【在 N********n 的大作中提到】
:
: 我的原文就在楼上。我明白的指出ASYNC是为了NON-BLOCKING I/O。既然都I/O
: 了，那当然不止一个module了，最典型的例子就是CLIENT/SERVER之间的交互
: 吗。你这里还在用单机思维去套。这个讨论一路看下来除了NIUHELIANG之外，
: 很多人连ASYNC的常见用途都不知道。
N*n
51 楼
ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
【在 p*u 的大作中提到】
: 其实事实刚好相反，是你和niuheliang根本不懂得software engineering中non-
: blocking和async两个concepts之间的区别，成天拿网站IO胡搅蛮缠。
h*c
52 楼
操作系统本身就是async的
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
【在 w***g 的大作中提到】
: async那套东西发展到极致，再加上一些syntactic suger，其实就是thread。
g*t
53 楼
Niheliang 说的有点不严格。因为他假设不用async, 那就会导致阻塞。这个不符合逻
辑。
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
【在 N********n 的大作中提到】
:
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
辑。
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
【在 N********n 的大作中提到】
:
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
s*e
54 楼
go 的 协成底层实现应该是 epoll 和 iocp。
.net 的 async 底层实现是 IOCP? 如果是的话，go 的协成跟async wait 不就一个意
思了吗？
http://www.cnblogs.com/superstar/archive/2012/03/14/2396136.html
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
.net 的 async 底层实现是 IOCP? 如果是的话，go 的协成跟async wait 不就一个意
思了吗？
http://www.cnblogs.com/superstar/archive/2012/03/14/2396136.html
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
s*e
55 楼
感觉 是 cpu 和 内存的 选择问题
https://medium.com/@alexyakunin/go-vs-c-part-1-goroutines-vs-async-await-
ac909c651c11
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
https://medium.com/@alexyakunin/go-vs-c-part-1-goroutines-vs-async-await-
ac909c651c11
【在 T********i 的大作中提到】
: 很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
: 器架构，都给予支持和保障。
: async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
: 引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
: 而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
: 连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。
h*e
56 楼
让你补课是我说的。到现在你还是认为async主要就是为了socket I/O，听说过GUI
programming么？
【在 N********n 的大作中提到】
:
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
programming么？
【在 N********n 的大作中提到】
:
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
n*g
57 楼
这么说吧，在汇编/机器级有中断这个概念。大致就是外设（I/O）有输入则发一个信号
给CPU，CPU就停下手头工作goto去处理一下。我的知识很陈旧了，是6502和8088开始的
，不知道现在发展成怎么样。特别是多核CPU如何处理中断。
Async其实机理和这个一致。硬件/CPU级中断现在受保护，只有OS能用。Async则是
framework提供一个类似的机制。
Async是个patch，解决IIS（其实Apache也有）的线程瓶颈问题。没有Async，服务器的
效率很低。如前端服务器要配很多CPU，而利用率不到15%。因为大多数工作就是转发然
后等待。用了Async，可以减少CPU核数，利用率高达60%-100%。
我知道还有其它实现技术。我没跟各种（开源）project。一个思路是自己写web
server。不要想得很难，我写过1-2个。自己处理进来的请求和调度。或者自己写
handler。对实时性要求比较高的应用，这是必须的。
ASYNC
【在 g****t 的大作中提到】
: Niheliang 说的有点不严格。因为他假设不用async, 那就会导致阻塞。这个不符合逻
: 辑。
:
:
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
:
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
:
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
:
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
:
给CPU，CPU就停下手头工作goto去处理一下。我的知识很陈旧了，是6502和8088开始的
，不知道现在发展成怎么样。特别是多核CPU如何处理中断。
Async其实机理和这个一致。硬件/CPU级中断现在受保护，只有OS能用。Async则是
framework提供一个类似的机制。
Async是个patch，解决IIS（其实Apache也有）的线程瓶颈问题。没有Async，服务器的
效率很低。如前端服务器要配很多CPU，而利用率不到15%。因为大多数工作就是转发然
后等待。用了Async，可以减少CPU核数，利用率高达60%-100%。
我知道还有其它实现技术。我没跟各种（开源）project。一个思路是自己写web
server。不要想得很难，我写过1-2个。自己处理进来的请求和调度。或者自己写
handler。对实时性要求比较高的应用，这是必须的。
ASYNC
【在 g****t 的大作中提到】
: Niheliang 说的有点不严格。因为他假设不用async, 那就会导致阻塞。这个不符合逻
: 辑。
:
:
: ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
:
: 是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
:
: 清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
:
: 为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
:
n*g
58 楼
没具体写过GUI的运算。但我觉得GUI运算并发度要求不高（你能有几块显卡），多线程
就行了，不需要Async。
【在 h****e 的大作中提到】
: 让你补课是我说的。到现在你还是认为async主要就是为了socket I/O，听说过GUI
: programming么？
就行了，不需要Async。
【在 h****e 的大作中提到】
: 让你补课是我说的。到现在你还是认为async主要就是为了socket I/O，听说过GUI
: programming么？
h*e
59 楼
all UI-related activity usually shares one thread。计算或者I/O类的东东交给其
他threads去做，用户要可以不停点击GUI提交requests。
GUI和显卡也没有是什么直接关系。
【在 n********g 的大作中提到】
: 没具体写过GUI的运算。但我觉得GUI运算并发度要求不高（你能有几块显卡），多线程
: 就行了，不需要Async。
他threads去做，用户要可以不停点击GUI提交requests。
GUI和显卡也没有是什么直接关系。
【在 n********g 的大作中提到】
: 没具体写过GUI的运算。但我觉得GUI运算并发度要求不高（你能有几块显卡），多线程
: 就行了，不需要Async。
n*g
60 楼
检讨一下，这个是我看错了。想着利用GPU加速的事情。这年头还在搞GUI的在鄙视链真
是比我这HTML程序员还低级。
用户界面这东西不能用async。其实就算是web的用async也要很小心，因为跑callback
的线程和开始的线程可能不是一个。如果有锁或解锁（如对context）可能死锁。
【在 h****e 的大作中提到】
: all UI-related activity usually shares one thread。计算或者I/O类的东东交给其
: 他threads去做，用户要可以不停点击GUI提交requests。
: GUI和显卡也没有是什么直接关系。
是比我这HTML程序员还低级。
用户界面这东西不能用async。其实就算是web的用async也要很小心，因为跑callback
的线程和开始的线程可能不是一个。如果有锁或解锁（如对context）可能死锁。
【在 h****e 的大作中提到】
: all UI-related activity usually shares one thread。计算或者I/O类的东东交给其
: 他threads去做，用户要可以不停点击GUI提交requests。
: GUI和显卡也没有是什么直接关系。
N*n
61 楼
没有ASYNC之前，GUI程序要经常检查自己在哪个线程上，避免GUI线程与WORKER
线程互踩脚趾头。有了ASYNC这种检查就不必要了。
ASYNC最主要的应用还是在SERVER端。现在点对点之间的CALL基本上都是ASYNC。
记得以前做CONSULTING, 一个公司的写的程序有瓶颈请我们去调。到哪里一看是
个初级程序员糙快猛写的程序，动辄用SYNC模式一个循环写几万次数据库。一到
这个循环就卡壳了。
我没功夫看STOR PROC里面搞啥。告诉他们先把SYNC模式换成ASYNC。就ASYNC这
一个补丁下去那一步的效率提高了1200%。HOHO
【在 n********g 的大作中提到】
: 没具体写过GUI的运算。但我觉得GUI运算并发度要求不高（你能有几块显卡），多线程
: 就行了，不需要Async。
n*g
62 楼
下次有机会让他们改成buck insert。一次写300-500条记录节省很多锁定和提交会快很
多倍。如果每个调用写很少，可以async到后台集中在一起写。对提高数据库吞吐量很
有帮助。
很多“初级程序员”用什么NoSQL，其实是不知道如何发挥关系数据库的性能。我见过
的应用规模没有几个是真正需要NoSQL的。
【在 N********n 的大作中提到】
:
: 没有ASYNC之前，GUI程序要经常检查自己在哪个线程上，避免GUI线程与WORKER
: 线程互踩脚趾头。有了ASYNC这种检查就不必要了。
: ASYNC最主要的应用还是在SERVER端。现在点对点之间的CALL基本上都是ASYNC。
: 记得以前做CONSULTING, 一个公司的写的程序有瓶颈请我们去调。到哪里一看是
: 个初级程序员糙快猛写的程序，动辄用SYNC模式一个循环写几万次数据库。一到
: 这个循环就卡壳了。
: 我没功夫看STOR PROC里面搞啥。告诉他们先把SYNC模式换成ASYNC。就ASYNC这
: 一个补丁下去那一步的效率提高了1200%。HOHO
多倍。如果每个调用写很少，可以async到后台集中在一起写。对提高数据库吞吐量很
有帮助。
很多“初级程序员”用什么NoSQL，其实是不知道如何发挥关系数据库的性能。我见过
的应用规模没有几个是真正需要NoSQL的。
【在 N********n 的大作中提到】
:
: 没有ASYNC之前，GUI程序要经常检查自己在哪个线程上，避免GUI线程与WORKER
: 线程互踩脚趾头。有了ASYNC这种检查就不必要了。
: ASYNC最主要的应用还是在SERVER端。现在点对点之间的CALL基本上都是ASYNC。
: 记得以前做CONSULTING, 一个公司的写的程序有瓶颈请我们去调。到哪里一看是
: 个初级程序员糙快猛写的程序，动辄用SYNC模式一个循环写几万次数据库。一到
: 这个循环就卡壳了。
: 我没功夫看STOR PROC里面搞啥。告诉他们先把SYNC模式换成ASYNC。就ASYNC这
: 一个补丁下去那一步的效率提高了1200%。HOHO
C*n
63 楼
async的优点是不等耗时的IO，这个对于调用在其他服务器的数据库有好处，或者调用
其他网络服务网页有好处，因为这些都需要几十毫秒或者几秒钟，这个远远超过
context switch的资源消耗。还有一个是async是在thread pool上实现的，thread
pool的优点是复用thread，如果要大量的生成短时间的thread，那么thread pool能够
节省生成新thread的开销，能够大幅提高服务器的performance。
其他网络服务网页有好处，因为这些都需要几十毫秒或者几秒钟，这个远远超过
context switch的资源消耗。还有一个是async是在thread pool上实现的，thread
pool的优点是复用thread，如果要大量的生成短时间的thread，那么thread pool能够
节省生成新thread的开销，能够大幅提高服务器的performance。
d*a
64 楼
我研究Python里面的corotine四五年了啊，有需要Python 多线程async外包的PM我啊。
s*n
65 楼
现实世界里，达到魏老师水准的美本小白码农，即使有的话，也不超过千分之一，让他
们弄thread, coroutine, 一是不愿学，学不会，二是即使有几个学会的，给你乱并发
乱锁一通，能拼对结果就谢天谢地，还敢想什么效率。Callback, async就是乱插队，
利用目前硬件冗余，系统大多数时间发呆这个空子，把原本需要魏老师三成功力才能做
的一些事，交给美本小白做成了。这是白人科技军事体系的过人之处，用顶层设计加超
级后勤，让三流士兵打赢战斗。
CS
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
们弄thread, coroutine, 一是不愿学，学不会，二是即使有几个学会的，给你乱并发
乱锁一通，能拼对结果就谢天谢地，还敢想什么效率。Callback, async就是乱插队，
利用目前硬件冗余，系统大多数时间发呆这个空子，把原本需要魏老师三成功力才能做
的一些事，交给美本小白做成了。这是白人科技军事体系的过人之处，用顶层设计加超
级后勤，让三流士兵打赢战斗。
CS
【在 T********i 的大作中提到】
: 不是thread，是coroutine。
: 而且，先天不足，根本不可能达到coroutine那个高度。
: 凭我这辈子的经验，我可以负责地说：async那一套纯粹是扯淡，发明者属于半吊子CS
: 毕业生，技术路线走偏了。
: 能流行起来，只能说这个世界太奇葩。
s*n
66 楼
在有许多服务窗口发呆的情况下，乱插队不失为一个好算法。比让一个啥X调度员堵死
了强不是
了强不是
相关阅读
FB vs Soros有没人可以推荐下2018 python 社区进展的文章i9-9900kJava其实也是前后端通吃的...魏老的产品，考虑上个十大吧请教怎么把几千行的源代码图形化便于理解？大家说说GraphQL这套为啥最近这么火？Tensorflow就是靠天吃饭啊在家学习深学的显卡折騰名詞，我覺得這裡的人永遠比不過MBA.Soap技术是不是趋近死亡？完蛋了完蛋了，我找人开发软件，后台用的是GOpipenv是python版的npm，有人有研究吗？我应该用什么语言或者framework？.net C# 有没有类似 go goroutine 的 库 或者框架 ？？如何使神经网络输出为正，或始终有一个下界golang IDE简单加密用哪个算法比较高校？ DES系列还是fish系列哪里有比较全的对比：比如说 Java ArrayList 就是 C++ vector有在CES的吗？