当前在线人数8410
首页 - 分类讨论区 - 电脑网络 - 葵花宝典版 - 同主题阅读文章

此篇文章共收到打赏
0

  • 10
  • 20
  • 50
  • 100
您目前伪币余额:0
未名交友
[更多]
[更多]
async那个架构其实很容易证明会增加复杂度的
[版面:葵花宝典][首篇作者:TeacherWei] , 2019年01月06日15:49:16 ,3041次阅读,58次回复
来APP回复,赚取更多伪币 关注本站公众号:
[首页] [上页][下页][末页] [分页:1 2 3 ]
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 1 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 15:49:16 2019, 美东)

很简单,sync的架构一直都保存context。context的管理,从编程语言,到OS,到处理
器架构,都给予支持和保障。

async那玩意儿,每次callback不可避免要把某些路径重走一遍。如果你不想重走,要
引入一系列中间状态,复杂度依然增加,背着抱着一般沉。

而且,你保存的一系列context,必然把local,global的一把抓都放在一起,尤其是多
连接伪并发的情况,自动机指数变大,很快就会变成恶梦。

这些还是忽略真正的多核并发的情况。
--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 74.]

 
wdong
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 2 ]

发信人: wdong (万事休), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 15:58:33 2019, 美东)

async那套东西发展到极致,再加上一些syntactic suger,其实就是thread。

【 在 TeacherWei (TW) 的大作中提到: 】
: 很简单,sync的架构一直都保存context。context的管理,从编程语言,到OS,到处理
: 器架构,都给予支持和保障。
: async那玩意儿,每次callback不可避免要把某些路径重走一遍。如果你不想重走,要
: 引入一系列中间状态,复杂度依然增加,背着抱着一般沉。
: 而且,你保存的一系列context,必然把local,global的一把抓都放在一起,尤其是多
: 连接伪并发的情况,自动机指数变大,很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。



--

※ 来源:·BBS 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 108.]

 
TheMatrix
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 3 ]

发信人: TheMatrix (TheMatrix), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 16:10:23 2019, 美东)

reinvent thread?

【 在 wdong (万事休) 的大作中提到: 】
: async那套东西发展到极致,再加上一些syntactic suger,其实就是thread。




--
☆ 发自 iPhone 买买提 1.24.09
--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2607:fb90:960:3]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 4 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 16:13:32 2019, 美东)

不是thread,是coroutine。
而且,先天不足,根本不可能达到coroutine那个高度。
凭我这辈子的经验,我可以负责地说:async那一套纯粹是扯淡,发明者属于半吊子CS
毕业生,技术路线走偏了。
能流行起来,只能说这个世界太奇葩。

【 在 wdong (万事休) 的大作中提到: 】
: async那套东西发展到极致,再加上一些syntactic suger,其实就是thread。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 74.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 5 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 17:06:07 2019, 美东)

容易懂。写起来容易。这也是个很大的优点。


【 在 TeacherWei(TW) 的大作中提到: 】
<br>: 不是thread,是coroutine。
<br>: 而且,先天不足,根本不可能达到coroutine那个高度。
<br>: 凭我这辈子的经验,我可以负责地说:async那一套纯粹是扯淡,发明者
属于半
吊子CS
<br>: 毕业生,技术路线走偏了。
<br>: 能流行起来,只能说这个世界太奇葩。
<br>

--
※ 修改:·guvest 於 Jan  6 17:06:32 2019 修改本文·[FROM: 2607:fb90:bd7:ec]
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 47.]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 6 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 17:14:10 2019, 美东)

coroutine更容易懂。写起来更容易。

【 在 guvest (我爱你老婆Anna) 的大作中提到: 】
: 容易懂。写起来容易。这也是个很大的优点。
: <br>: 不是thread,是coroutine。
: <br>: 而且,先天不足,根本不可能达到coroutine那个高度。
: <br>: 凭我这辈子的经验,我可以负责地说:async那一套纯粹是扯淡,发明者
: 属于半
: 吊子CS
: <br>: 毕业生,技术路线走偏了。
: <br>: 能流行起来,只能说这个世界太奇葩。
: <br>



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 74.]

 
mjyu
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 7 ]

发信人: mjyu (杀猪的), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 17:17:42 2019, 美东)

回过头来看看,其实除了基本教科书的那点东西,其它都是扯淡。
但马工的特点是,不让他们扯淡,不舒服啊。

--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 216.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 8 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 17:29:18 2019, 美东)

但go這種出現的晚啊。go寫起來難度和python差不多。
假如早出現一些時間,也許就沒python什麼事了
【 在 TeacherWei(TW) 的大作中提到: 】
<br>: coroutine更容易懂。写起来更容易。
<br>

--
※ 修改:·guvest 於 Jan  6 17:30:30 2019 修改本文·[FROM: 47.]
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 47.]

 
wdong
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 9 ]

发信人: wdong (万事休), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 20:04:43 2019, 美东)

CS里面,system和language是两个非常独立的分支。搞language的人,有的要
写编译器做优化,倒是懂system,但是system的人对language的理解还停留
在按face value理解C语言的层次,对新语言的设计靠的也还是朴素的经验
而没上升到科学的层次。

这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。

【 在 TeacherWei (TW) 的大作中提到: 】
: 不是thread,是coroutine。
: 而且,先天不足,根本不可能达到coroutine那个高度。
: 凭我这辈子的经验,我可以负责地说:async那一套纯粹是扯淡,发明者属于半吊子
CS
: 毕业生,技术路线走偏了。
: 能流行起来,只能说这个世界太奇葩。



--

※ 来源:·BBS 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 108.]

 
TeacherWei
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 10 ]

发信人: TeacherWei (TW), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 20:27:14 2019, 美东)

说反了吧?搞language的,都要做bare metal,编译的代码要没system也能用。甚至是
凭空无中生有编译出system来。

比如这个I/O问题。其实用C,把所有的system call都wrap一遍,做个coroutine出来,
也是可以的。代价也不高。但是貌似从来没人做过。

从这点来看,go确实有意无意地填补了一项空白。

【 在 wdong (万事休) 的大作中提到: 】
: CS里面,system和language是两个非常独立的分支。搞language的人,有的要
: 写编译器做优化,倒是懂system,但是system的人对language的理解还停留
: 在按face value理解C语言的层次,对新语言的设计靠的也还是朴素的经验
: 而没上升到科学的层次。
: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
: CS



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 74.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 11 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 21:00:16 2019, 美东)

用c做goroutine,做了又没人推广,又没有收入,那不是白做.
我以前的公司,好多老师傅
老师傅写几个while死循环,加上几行汇编写成的yield安稳混饭十几年。


【 在 TeacherWei(TW) 的大作中提到: 】
<br>: 说反了吧?搞language的,都要做bare metal,编译的代码要没system也能用。
甚至是
<br>: 凭空无中生有编译出system来。
<br>: 比如这个I/O问题。其实用C,把所有的system call都wrap一遍,做个coroutine
出来,
<br>: 也是可以的。代价也不高。但是貌似从来没人做过。
<br>: 从这点来看,go确实有意无意地填补了一项空白。
<br>
--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 66.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 12 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 21:01:58 2019, 美东)

外行人懂应用,市场上转一圈,带着用户回过头来消灭内行人。


【 在 wdong(万事休) 的大作中提到: 】
<br>: CS里面,system和language是两个非常独立的分支。搞language的人,有
的要
<br>: 写编译器做优化,倒是懂system,但是system的人对language的理解还停留
<br>: 在按face value理解C语言的层次,对新语言的设计靠的也还是朴素的经验
<br>: 而没上升到科学的层次。
<br>: 这世界就是这么奇葩。外行人骗外行人能骗出一个经济出来。
<br>: CS
<br>

--
※ 修改:·guvest 於 Jan  6 21:02:30 2019 修改本文·[FROM: 66.]
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 66.]

 
netghost
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 13 ]

发信人: netghost (Up to Isomorphism), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 22:23:03 2019, 美东)

async是很多過程的自然現象。網絡交互的特性就是async的,所以也只能這麼去處理。
至於說現在很多人知道的那個"async",你也知道,面向對像這東西有用沒?我覺得是有
的,
但是大部分人懂的那個OOP是不是個shit,也是一樣的shit。

我認為計算機行業最大的問題就是,現在系統要求開發人員懂某些複雜的結構,但是人
群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造出的輪子,
either不是一個這些人能用的輪子,要不就不是一個真正的輪子。
【 在 TeacherWei (TW) 的大作中提到: 】
: 很简单,sync的架构一直都保存context。context的管理,从编程语言,到OS,到处理
: 器架构,都给予支持和保障。
: async那玩意儿,每次callback不可避免要把某些路径重走一遍。如果你不想重走,要
: 引入一系列中间状态,复杂度依然增加,背着抱着一般沉。
: 而且,你保存的一系列context,必然把local,global的一把抓都放在一起,尤其是多
: 连接伪并发的情况,自动机指数变大,很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。



--

※ 来源:·BBS 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 96.]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 14 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Sun Jan  6 22:37:22 2019, 美东)

对的。面向机器多一些的语言另外还有一个众口难调的问题。所以面向人多一些的语言
,basic, perl, python, js 这条线也会一直有自己的发展。
就是因为轮子更加容易使用中。

【 在 netghost(Up to Isomorphism) 的大作中提到: 】
<br>: async是很多過程的自然現象。網絡交互的特性就是async的,所以也只能
這麼去
處理。
<br>: 至於說現在很多人知道的那個"async",你也知道,面向對像這
東西有用沒?我覺
得是有
<br>: 的,
<br>: 但是大部分人懂的那個OOP是不是個shit,也是一樣的shit。
<br>: 我認為計算機行業最大的問題就是,現在系統要求開發人員懂某些複雜的
結構,
但是人
<br>: 群中能懂這些東西的人的比例遠遠小於行業的需求。所以針對大部分人造
出的輪
子,
<br>: either不是一個這些人能用的輪子,要不就不是一個真正的輪子。
<br>

--
※ 修改:·guvest 於 Jan  6 23:20:25 2019 修改本文·[FROM: 47.]
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 66.]

 
niuheliang
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 15 ]

发信人: niuheliang (别问我是谁), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan  7 00:01:29 2019, 美东)

在一个系统里,线程的数量有限。

在互联网应用中,如果因为等待如I/O而占用线程会限制了单机最大并发用户数。

async是在挂起等待时线程可以被重用。因此去除了一个瓶颈。



【 在 TheMatrix (TheMatrix) 的大作中提到: 】
: reinvent thread?



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2600:1700:4570:]

 
niuheliang
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 16 ]

发信人: niuheliang (别问我是谁), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan  7 00:06:36 2019, 美东)

https://zhuanlan.zhihu.com/p/31803596

如这个,无论是1024线程/进程(网络服务占用一个进程)还是65536线程/进程,在互
联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用资源,
完全不实用。


【 在 TheMatrix (TheMatrix) 的大作中提到: 】
: reinvent thread?



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 2600:1700:4570:]

 
guvest
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 17 ]

发信人: guvest (我爱你老婆Anna), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan  7 02:26:45 2019, 美东)

你这个说的是并发问题。这个问题好几年前本版似乎充分讨论过了。老师傅也容易找。

我希望有多线程主要是要并行多核数值计算。


【 在 niuheliang(别问我是谁) 的大作中提到: 】
<br>: https://zhuanlan.zhihu.com/p/31803596
<br>: 如这个,无论是1024线程/进程(网络服务占用一个进程)还是65536线程/进程
,在互
<br>: 联网应用中都是很小的数字。特别是AJAX应用很多是连上了就不断。sync太占用
资源,
<br>: 完全不实用。
<br>
--
※ 来源:· 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 66.]

 
xiaoju
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 18 ]

发信人: xiaoju (可爱的龙猫), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan  7 06:33:10 2019, 美东)

大哥,看看async/await的定义先

【 在 TeacherWei (TW) 的大作中提到: 】
: 很简单,sync的架构一直都保存context。context的管理,从编程语言,到OS,到处理
: 器架构,都给予支持和保障。
: async那玩意儿,每次callback不可避免要把某些路径重走一遍。如果你不想重走,要
: 引入一系列中间状态,复杂度依然增加,背着抱着一般沉。
: 而且,你保存的一系列context,必然把local,global的一把抓都放在一起,尤其是多
: 连接伪并发的情况,自动机指数变大,很快就会变成恶梦。
: 这些还是忽略真正的多核并发的情况。



--

※ 来源:·BBS 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 27.]

 
pxu
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 19 ]

发信人: pxu (又呱噪又抠门还偷老婆钱), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan  7 11:50:48 2019, 美东)

programming languages有很多种,focus也不同。C/Golang是为了system programming
,Scheme这类的functional language则不适,不可一概而论。


【 在 TeacherWei (TW) 的大作中提到: 】
: 说反了吧?搞language的,都要做bare metal,编译的代码要没system也能用。甚至是
: 凭空无中生有编译出system来。
: 比如这个I/O问题。其实用C,把所有的system call都wrap一遍,做个coroutine出来,
: 也是可以的。代价也不高。但是貌似从来没人做过。
: 从这点来看,go确实有意无意地填补了一项空白。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 204.]

 
silverhawk
进入未名形象秀
我的博客
[回复] [回信给作者] [本篇全文] [本讨论区] [修改] [删除] [转寄] [转贴] [收藏] [举报] [ 20 ]

发信人: silverhawk (silverhawk), 信区: Programming
标  题: Re: async那个架构其实很容易证明会增加复杂度的
发信站: BBS 未名空间站 (Mon Jan  7 13:13:11 2019, 美东)

async 和thread两回事把,一个是实现手段,一个是设计理念。thread 可以做
coroutine这样的,也可以做premptive这样的。
【 在 TeacherWei (TW) 的大作中提到: 】
: 不是thread,是coroutine。
: 而且,先天不足,根本不可能达到coroutine那个高度。
: 凭我这辈子的经验,我可以负责地说:async那一套纯粹是扯淡,发明者属于半吊子
CS
: 毕业生,技术路线走偏了。
: 能流行起来,只能说这个世界太奇葩。



--
※ 来源:·WWW 未名空间站 网址:mitbbs.com 移动:在应用商店搜索未名空间·[FROM: 167.]

[首页] [上页][下页][末页] [分页:1 2 3 ]
[快速返回] [ 进入葵花宝典讨论区] [返回顶部]
回复文章
标题:
内 容:

未名交友
将您的链接放在这儿

友情链接


 

Site Map - Contact Us - Terms and Conditions - Privacy Policy

版权所有,未名空间(mitbbs.com),since 1996