[email protected]:~$

  • fiber, goroutine/erlang process, thread的区别

    经常看到有人会认为fiber和thread是一类东西,或者认为fiber就是轻量级的thread,和goroutine / erlang process是同一种东西 JRuby的fiber目前也是用thread来实现的,可能因此引起很多fiber和thread的误解 当然它们当然不是同一种概念..(两个当然!!哦不..三个!!) thread是一种“执行单位”,操作系统会分配CPU去运行thread。goroutine和erlang process与此相近,相比thread更加的轻量化(貌似听说过goroutine就是简单的通过线程池来实现),所以它们也是“执行单位”。概念上thread 和goroutine / erlang process更加接近,都会由VM或OS(OS也可看做是VM!)分配CPU时间去执行。 fiber与此不同,打个简单的比方,如果你用了两个线程,并且你用的双核电脑,这时你的代码很有可能会跑在两个CPU上。 如果你用了两个fiber会怎么样?当你调用run的时候并不会新开始一个“执行单位”,fiber的调用是在你当前的thread执行的,fiber的call需要占用“执行单位”(通常是thread),因为其本身不是一个“执行单位”。 fiber是在“执行单位”之上的,与thread不是同一个概念,fiber用来保存“执行流程”,仅仅是保存,这样可以把“执行流程”从“执行单位”上抽离,更加有效的利用“执行单位”。 Celluloid(ruby的一个实现actor model的库)中Actor就是这样的用法,可以让本应被block的“执行流程”暂时保存在fiber中,这时“执行单位”(其实就是thread)可以执行下一个“流程”,让thread的利用率更高。 em-synchrony则更巧妙的通过fiber切换“执行流程”来达到写同步代码,异步执行(有兴趣可以看em-synchrony在github主页上的链接,里面讲了如何实现) 这样看的话就很清晰了,thread和goroutine / erlang process 这些都是“执行单位”,可以获得CPU时间。fiber的用处则是保存“执行流程”,与前者完全不是同一个概念。

  • 2014年凌晨的胡思乱想

    没有实感 对于电脑右下角年份的切换没有特别的感觉 好像和昨天一样,昨天又和前天一样 最近偶尔会发呆,在不知道做什么事时突然楞在那里,就好像大脑回路里某个字节出现了错误,或者像是输入设备出了bug,迟迟不能接收外界 思考了很多,感觉最近在技术上找不到方向,不知道做什么,可能是眼高手低,很简单的不屑于去做,很难的水平又不够,翻下github就知道我没有自己做过web项目(blog可以忽略了吧)。为什么?没什么意义,不想做千篇一律的东西,不想做一个又一个的BBS,Blog,没有什么有趣的想法,做出来的也都是废物 可能这也是一种回避思考,知道做出来后没什么用,于是就不做,很聪明的选择,知道即使学了llvm能做出玩具语言,但没什么用,于是看着看着乏味了就放弃了。因为明知是失败,无意义,乏味的东西,所以主动放弃,这种回避做法是聪明吗? 感觉不仅是职业上,在生活上也找不到方向,昨天等于今天等于明天,害怕被拒绝于是回避和别人的对话,感觉说出来会被无视于是不做声,感觉语言是无意义的于是尽量寡言。其实语言明明是很重要的东西,无论其承载,语言本身就是很重要的。很羡慕Cai*那种性格,某次RubyTuesday明明最晚到,却能强制的插入话题,并且引导话题到自己的产品,这种气势似乎是先天得来,有些猎命师里‘命格’的感觉。所以该说是性格使然吗?性格是命运吗?如果一个人出生带有的性格决定其做法或对其做出的选择至少会有影响,那么这算是命运吗? 性格决定命运,命运决定环境,环境决定性格。应该由哪一环来打破? 环境?环境是最薄弱的一环,想做的话甚至辞职换个城市生活就可以了。 这不是逃避,绝对不是,浑浑噩噩的生活才是逃避,打破负面的循环是一种面对,是一种尝试 但是这种选择往往伴随着新的枷锁,选择打破环境可能会带来新鲜感,于是本质的问题暂时被掩盖,但总还会有浮上来的一天,那时又该怎么办? 自视甚高是凡人的可悲,明明对自己要求很高,目光中充满不屑,却达不到这种要求,想象中与现实中的自我产生极大差异。我能想到的结果其一自欺欺人,其二不满现实郁郁而终 是不是真的有贤人?无欲无求的人和庸人区别在何处?所以那些人又为什么被成为圣贤? 感到自己缺少‘匠’心,无论做什么都很烦躁,从技术上或是爱好上都能看出,不想学基础却一直想着做出什么有用的东西,平时的小说也基本都是一晚上完成的,回过头看很是粗糙,有些明明有趣的故事,因为着急展开,压缩字数,导致铺垫不足,完全渣掉了 其实想当的是演奏家,对此没有执着,只是感觉当个流浪的演奏家是很惬意的事情。独自来到小村子,用演奏来换取住处食物和村人的友情,生活一段时间后在夕阳中悄然离去,只留下背影。如果遇到同样的流浪艺人还能组个队什么的。当然只是一种幻想中的理想生活,精神寄托,所以只能想,更何况自己演奏水平低,流浪这种事情更做不来。 写完后感觉有点像是反省录?不过缺点这种东西不是意识到了就可以改的,写下来也不行! 不过既然人无完人,那么是否有必要改正所谓缺点?还是说缺点也只是人的构成部分而已,每个齿轮都有凹凸 2014年意义不明的一篇文章,新的一年要想有长进最简单的先从早睡开始吧? 起床时就是2014年的第一次醒来了

  • Yet Another Markdown Parser, 没想到还原度还挺高的

    最近写了个markdown parser练手, 发现这种有规范的东西非常适合TDD, 照着markdown语法来写spec, 然后一个一个将其通过, 之前从未试过这么彻底的TDD 是写代码写的很爽时顾不上测试 是spec一定要事先定下,如果是创造性的编程, spec没法确定, 在代码和spec间来回改动就失去了TDD的意义 托TDD的福,写好各个语法的parse后跑了下GFM的source页,没想到还原度还挺高的 之后fix了几个小地方,parse的效果已经比较完善了,而且因为TDD 保证了测试的覆盖率(2k行左右的代码估计1k多都是spec),可以放心的修改代码,只要可以pass spec基本就是没问题的 之前一直感觉TDD有点名副其实, 经过这次实践感觉这种编程方式真的能帮助你写出可靠的代码 当然关键还是要事先确定spec, 如果不能确定spec我是绝不会用TDD的方式去开发的, 实际上我把minidown改成支持GFM时就改动了一些spec, 当然相应之前的所有代码也需要修改,相当于白写了一遍测试 benchmark了下各种markdown parser解析14000篇文章的效率 跑在the ruby racer 上的marked大概3.8s可以完成 minidown 大概16s可以完成 maruku报错.. kramdown 大概200+s可以完成…(这货README里写着fast..) 后3种都是pure ruby的markdown parser marked考虑到主要是前端使用,可能没有太多考虑效率,看得出ruby和v8差距还是挺大… 对于后边两个结果到是很惊讶, 没想到minidown在pure ruby的parser里还挺快的..