经过近一个月的研究，初步实现了一个c/c++的协程平台，并成功移植到了python

[sailing]

二十多天以前，受stackless的启发，打算在c++上做一个协程支持平台。经过两个星期的死磕，一个雏形终于诞生了！经测试，协程切换开销最快时
平均耗费43.6个cpu周期，对这个效率颇感欣慰，不枉忙了一个大年啊。

这两天成功地将其接口移植到了python上，等到成熟到一定程度，会考虑做成开源项目。
以后只需要一个python库，不再需要安装stackless python了！（不过貌似python库里面早有这种东东哈，叫greenlet？
应该是类似的机制实现的吧）

[王健/Beckie]

为什么不用stackless，要用C++写啊

======= 2010-02-23 09:15:16 您在来信中写道：=======

>--
>您收到此邮件是因为您订阅了 Google 网上论坛的“eurasia-users”论坛。
>要向此网上论坛发帖，请发送电子邮件至 eurasi...@googlegroups.com。
>要取消订阅此网上论坛，请发送电子邮件至 eurasia-user...@googlegroups.com。
>若有更多问题，请通过 http://groups.google.com/group/eurasia-users?hl=zh-CN 访问此网上论坛。
>

= = = = = = = = = = = = = = = = = = = =


　　　　　　　　致
礼！


　　　　　　　　王健/Beckie
　　　　　　　　charl...@gmail.com
　　　　　　　　　　2010-02-23

[Eric.M]

C++里是不是有一个叫纤程的，类似greenlet

[sailing]

呵呵，因为重新发明一下轮子，蛮快乐的^_^。
c++效率高啊～
这是我计划中的一个分布式游戏服务器框架的第一步。以前打算用基于事件的模型去写的，后来调研后发现那种写法很不方便，开发效率上肯定没有用传统“阻塞
式”思维编程的效率高；而且代码耦合度高，不方便重用。
这个时候发现了eurasia，因此连带认识了stackless python这个牛叉闪闪的东东。但是python的GIL很让人恼火，大家知道
twisted（它的编程方式确实很“纠结”），它在处理数据库的时候，由于缺乏足够的异步数据库接口支持，采用线程的方式来达到一个异步的效果，这时
候GIL的问题就显露出来了。另外现在我知道的所有orm实现都是基于阻塞的方式工作，我本来非常期待着eurasia能给出一个完美的数据库解决方案
的，暂时看看貌似没有动静。后来想，与其等，还不如自己来……
不用stackless的另一个原因是开始并没有打算全部用Python来写，计划是底层用c++，上层逻辑部分基本用python，要求效率的逻辑部
分用c++。因此看到eurasia的时候很高兴地觉得自己可以偷个懒了，不过最终仍然因为GIL的问题，让我觉得stackless python很
鸡肋，c++模块无法在stackless提供的平台上放开手脚。所以后来这个协程平台是为C++写的，不过经过快乐地试验发现它做成python库的
话，最终能够成为stackless的替代者。

写完了这个以后，觉得stackless python这样修改python解释器来支持协程的做法并非必要。python这种基于c栈工作的解释器，
可以直接用c和asm代码在栈上动手，效率大大的～。

[sailing]

嗯，windows里有这么一个东东，fiber，但我不知道linux里面的有什么替代物。我写的这个协程库是需要跨平台的。
原来boost库里提供一个协程实现，不过后来这个东东消失了。我很奇怪协程这种最高效的并发方式在c++的高并发场景中却很少有人用，很多人仅仅"听
说"过而已。结果现在c++里连一个有人气的协程库都难找。

On Feb 23, 5:22 am, "Eric.M" <frederick....@gmail.com> wrote:
> C++里是不是有一个叫纤程的，类似greenlet
>

[黄毅]

2010/2/23 sailing <forever...@gmail.com>

呵呵，因为重新发明一下轮子，蛮快乐的^_^。
c++效率高啊～
这是我计划中的一个分布式游戏服务器框架的第一步。以前打算用基于事件的模型去写的，后来调研后发现那种写法很不方便，开发效率上肯定没有用传统“阻塞
式”思维编程的效率高；而且代码耦合度高，不方便重用。
这个时候发现了eurasia，因此连带认识了stackless python这个牛叉闪闪的东东。但是python的GIL很让人恼火，大家知道
twisted（它的编程方式确实很“纠结”），它在处理数据库的时候，由于缺乏足够的异步数据库接口支持，采用线程的方式来达到一个异步的效果，这时
候GIL的问题就显露出来了。另外现在我知道的所有orm实现都是基于阻塞的方式工作，我本来非常期待着eurasia能给出一个完美的数据库解决方案
的，暂时看看貌似没有动静。后来想，与其等，还不如自己来……
不用stackless的另一个原因是开始并没有打算全部用Python来写，计划是底层用c++，上层逻辑部分基本用python，要求效率的逻辑部
分用c++。因此看到eurasia的时候很高兴地觉得自己可以偷个懒了，不过最终仍然因为GIL的问题，让我觉得stackless python很
鸡肋，c++模块无法在stackless提供的平台上放开手脚。所以后来这个协程平台是为C++写的，不过经过快乐地试验发现它做成python库的
话，最终能够成为stackless的替代者。 

写完了这个以后，觉得stackless python这样修改python解释器来支持协程的做法并非必要。python这种基于c栈工作的解释器，
可以直接用c和asm代码在栈上动手，效率大大的～。

直接修改cpython还是有其好处的，比如对纯python代码的tasklet可以实现快速的 soft switch，完全不涉及堆栈的操作，调整一个frame对象的指针即可。
另外一个特性就是tasklet pickle，只能修改CPython来实现的
 

王健/Beckie wrote:
> 为什么不用stackless，要用C++写啊
>
> ======= 2010-02-23 09:15:16 您在来信中写道：=======
>
> >二十多天以前，受stackless的启发，打算在c++上做一个协程支持平台。经过两个星期的死磕，一个雏形终于诞生了！经测试，协程切换开销最快时
> >平均耗费43.6个cpu周期，对这个效率颇感欣慰，不枉忙了一个大年啊。
> >
> >这两天成功地将其接口移植到了python上，等到成熟到一定程度，会考虑做成开源项目。
> >以后只需要一个python库，不再需要安装stackless python了！（不过貌似python库里面早有这种东东哈，叫greenlet？
> >应该是类似的机制实现的吧）
> >
> >--
> >您收到此邮件是因为您订阅了 Google 网上论坛的“eurasia-users”论坛。
> >要向此网上论坛发帖，请发送电子邮件至 eurasi...@googlegroups.com。
> >要取消订阅此网上论坛，请发送电子邮件至 eurasia-user...@googlegroups.com。
> >若有更多问题，请通过 http://groups.google.com/group/eurasia-users?hl=zh-CN 访问此网上论坛。
> >
>
> = = = = = = = = = = = = = = = = = = = =
>
>
> 致
> 礼！
>
>
> 王健/Beckie
> charl...@gmail.com
> 2010-02-23

--
您收到此邮件是因为您订阅了 Google 网上论坛的“eurasia-users”论坛。
要向此网上论坛发帖，请发送电子邮件至 eurasi...@googlegroups.com。
要取消订阅此网上论坛，请发送电子邮件至 eurasia-user...@googlegroups.com。
若有更多问题，请通过 http://groups.google.com/group/eurasia-users?hl=zh-CN 访问此网上论坛。

--
http://codeplayer.blogspot.com/

[simon]

发现sailing同学两年前的帖子。我对c++的协程和python研究有兴趣。能否邮件一下。这里竟然查不到你的邮件地址。不知项目是否开源了？？？
找不到人只有挖坟了。

在 2010年2月23日星期二UTC+8上午9时15分01秒，sailing写道：