发信人: TeacherWei (TW), 信区: Programming
标 题: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan 6 15:49:16 2019, 美东)
很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
器架构，都给予支持和保障。
async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
这些还是忽略真正的多核并发的情况。
发信人: wdong (万事休), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan 6 20:04:43 2019, 美东)
CS里面，system和language是两个非常独立的分支。搞language的人，有的要
写编译器做优化，倒是懂system，但是system的人对language的理解还停留
在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
而没上升到科学的层次。
这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
发信人: netghost (Up to Isomorphism), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan 6 22:23:03 2019, 美东)
async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能這麼去處理。
至於說現在很多人知道的那個"async",你也知道，面向對像這東西有用沒？我覺得是有
的，
但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的結構，但是人
群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子，
either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 两个死循环互相goto的话。可以在脑子里去掉callee和caller的概念。
: 我想前面好几位的意思是，非阻塞不一定需要async await那样处理。
: 例如你也可以自己写一个处理这类问题。例如把jump back forth所需附带的上下文包
: 装成函数的call。
楼上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是在挂起等待时线程可以被重用。因此去除了一个瓶颈。
发信人: NeverLearn (24K golden bear), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Tue Jan 8 19:28:56 2019, 美东)
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: Goroutines 类似的东西在其他语言里也有啊。
: 不一定async／await才能IO解决阻塞问题。
: 你也可以自己写一个所谓的lightweightthread。
: 取个名字叫做TaskLeaf
: 为什么要在async，await一棵树上挂着才可以解决IO阻塞？
: 我感觉这不符合逻辑。也不符合现实情况。
总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
/AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
发信人: NeverLearn (24K golden bear), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Wed Jan 9 18:11:09 2019, 美东)
【 在 pxu (又呱噪又抠门还偷老婆钱) 的大作中提到: 】
: 其实事实刚好相反，是你和niuheliang根本不懂得software engineering中non-
: blocking和async两个concepts之间的区别，成天拿网站IO胡搅蛮缠。
ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
发信人: niuheliang (别问我是谁), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Thu Jan 10 13:32:47 2019, 美东)
这么说吧，在汇编/机器级有中断这个概念。大致就是外设（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那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan 6 15:49:16 2019, 美东)
很简单，sync的架构一直都保存context。context的管理，从编程语言，到OS，到处理
器架构，都给予支持和保障。
async那玩意儿，每次callback不可避免要把某些路径重走一遍。如果你不想重走，要
引入一系列中间状态，复杂度依然增加，背着抱着一般沉。
而且，你保存的一系列context，必然把local，global的一把抓都放在一起，尤其是多
连接伪并发的情况，自动机指数变大，很快就会变成恶梦。
这些还是忽略真正的多核并发的情况。
发信人: wdong (万事休), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan 6 20:04:43 2019, 美东)
CS里面，system和language是两个非常独立的分支。搞language的人，有的要
写编译器做优化，倒是懂system，但是system的人对language的理解还停留
在按face value理解C语言的层次，对新语言的设计靠的也还是朴素的经验
而没上升到科学的层次。
这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
发信人: netghost (Up to Isomorphism), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan 6 22:23:03 2019, 美东)
async是很多過程的自然現象。網絡交互的特性就是async的，所以也只能這麼去處理。
至於說現在很多人知道的那個"async",你也知道，面向對像這東西有用沒？我覺得是有
的，
但是大部分人懂的那個OOP是不是個shit，也是一樣的shit。
我認為計算機行業最大的問題就是，現在系統要求開發人員懂某些複雜的結構，但是人
群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子，
either不是一個這些人能用的輪子，要不就不是一個真正的輪子。
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 两个死循环互相goto的话。可以在脑子里去掉callee和caller的概念。
: 我想前面好几位的意思是，非阻塞不一定需要async await那样处理。
: 例如你也可以自己写一个处理这类问题。例如把jump back forth所需附带的上下文包
: 装成函数的call。
楼上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是在挂起等待时线程可以被重用。因此去除了一个瓶颈。
发信人: NeverLearn (24K golden bear), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Tue Jan 8 19:28:56 2019, 美东)
【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: Goroutines 类似的东西在其他语言里也有啊。
: 不一定async／await才能IO解决阻塞问题。
: 你也可以自己写一个所谓的lightweightthread。
: 取个名字叫做TaskLeaf
: 为什么要在async，await一棵树上挂着才可以解决IO阻塞？
: 我感觉这不符合逻辑。也不符合现实情况。
总之不能用SYNC在那里BLOCKING THREAD，对不对？这个是基本出发点，至于是用ASYNC
/AWAIT还是什么更好的方式其他可以另说。相比于SYNC模式，ASYNC消除了
SERVER端THREAD BLOCKING这个瓶颈，这个就是其优点。
其实你找几个做过电商网站的问问就知道了。他们的WEB SERVICE大量都是ASYNC
CALL。否则到了高峰期一旦THREAD POOL BLOCKING，网站马上就卡住了。
发信人: NeverLearn (24K golden bear), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Wed Jan 9 18:11:09 2019, 美东)
【 在 pxu (又呱噪又抠门还偷老婆钱) 的大作中提到: 】
: 其实事实刚好相反，是你和niuheliang根本不懂得software engineering中non-
: blocking和async两个concepts之间的区别，成天拿网站IO胡搅蛮缠。
ASYNC流行是因为可以用来缓解互联网I/O阻塞的，其他形式的阻塞也可以考虑但
是主要用途是在互联网程序上。NIUHELIANG早就点明这一点，你们还在那里拎不
清。什么一个MODULE、SOFTWARE ENGINEERING风马牛不相及的都来了。连ASYNC
为啥流行、在哪里适用都不知道，还要给别人“科普”、“补课”, HOHOHO。
发信人: niuheliang (别问我是谁), 信区: Programming
标 题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Thu Jan 10 13:32:47 2019, 美东)
这么说吧，在汇编/机器级有中断这个概念。大致就是外设（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。对实时性要求比较高的应用，这是必须的。
Comments
Post a Comment
https://gengwg.blogspot.com/