stackless python 给我们带来了什么？

[pythonee]

因为GIL，python在并发的的方向大概往两个方向，一个是更大，也就是多进程，这个可能是最好的，如果配上消息的话，一个是更小，也就是协程，stackless python就是这种，但是python原本因为GIL的一些限制，stackless python并不能帮我们突破，比如不能利用多核CPU、比如python的线程调度依赖操作系统的信号等，该存在还是存在，但是stackless python确实有应用场合，已经应用到了很多地方，比如家都知道的eve，还有我们沈威的eurasia服务器，所以我就想stackless应该用在什么地方，我只想到stackless配上异步IO来最大化的节省IO等待和线程切换的成本，但这就不关stackless什么事了，其实是异步带来的好处，stackless不过让我们更好的表达程序而已，不知道大家都有哪些关于stackless的总结

我很赞成一个观点，我们再也不能把stackless当作python的另一个私生子来看待，所以就想讨论一下这个话题

就在v2ex,看到有人说有论文称服务器的发展是多进程=>多线程=>异步=>协程
要是有人能给我看看这个论文就好了

[lookhi]

换Go了

[pythonee]

@lookhi
你是说stackless比不上goroutine吗，那我就换个方式吧，用户级线程给我们带来了什么

[BigZ]

当做erlang的python,有点gevent的意思

[myrual]

@pythonee 从设计上说代码更可维护，同时性能很好。

[pythonee]

@myrual

其实我就想知道性能会更好的原因，性能也会更差的！
目前了解到的是，协程可以理解为异步的封装，那么异步的单独使用是不会利用到多核的，协程的单独使用也不会提高性能，但是这两者的结合，就会充分发挥cpu的性能，多协程间的切换成本低，封装异步使得代码可读性高，目前了解就这么多，欢迎讨论

[pythonee]

@BigZ
gevent不就是从stackless剥出去的吗

[myrual]

@pythonee 操作系统级别的线程切换是需要copy大量的数据，导致cpu的很多时间用在切换进和切换出上，而用户级别的协程切换与操作系统无关，个人猜测任务切换需要的数据量相对少很多，同时维护任务的上下文需要的数据量也很小，所以并发任务数量可以很多。
举个例子：
goroutine和gevent都不是抢占式任务调度，而是当发生系统调用的时候进行切换。

个人猜测为了更加经济的支持多任务兵法，goroutine和gevent的设计是有意选择非抢占式调度。

以上均为个人猜测。
总结一下就是：以前至少用1M内存才能支撑完成一个任务，现在用1k来支撑，任务切换以前要用1秒，现在0.1秒。
所以性能提升了。
但是如果某个任务就是非常耗时，非常耗内存，那么其实没区别。
所以性能提升的另一个前提是， 大量的并发中只有少部分真在工作，剩下的大部分都在休息。
否则性能无法提升

[pythonee]

@myrual 用户级别线程轻量，轻轻松松就可以创建1w个，这真不是提升性能的关键，如果每个tasklet里面的操作都是阻塞的，那么很可能就更差了，因为这些tasklet不是真并发，他们这时候变成了串行，让他们切换的关键是异步IO，一个tasklet不至于阻塞别的tasklet，而这个切换成本很低很低

第二个前提提醒了我，但是这不是多线程，多钎程所能解决的了，这时候真的就是使用更好的机器，换计算模型的时候了

[myrual]

@pythonee 你说的对，用户级别的线程能发挥作用的场景是有若干限制条件的。
1. 一个线程(一组线程)对应一个单独的服务对象，不同的服务对象之间不存在依赖关系。
2. 大多数时候线程处于休息状态。
3. 线程工作的时候负载不大，工作时间很短。
4. 服务器同时持有大量不活跃的服务对象的负担很小。

[shymonk]

写了一篇关于 stackless 的文章，可以参考。
http://shymonk.com/posts/2016/06/stackless-python-tan-mi/