RUST网络客户端的基本技术说明-协程

一、协程

首先说明的是，Rust对协程的支持是一波三折，对RUST的相关技术还是了解的有所欠缺，所以对RUST认知是现在原生是不支持协程的。但可以通过一些库或者自己编写来实现协程。比较有名的TOKIO这个库。可以把其中的Task当作是协程。理解是理解，其实它不是协程，要明白这一点。
早先RUST有runtime机制和协程，后来大佬们觉得可能这玩意儿和RUST设计的初衷有所违背，所以就砍了。不服不行，真的。RUST原来有一个绿色线程，其实就是协程模型。

二、Rust对协程的支持

绿色线程，也可以按经典的协程的说法叫做用户态线程，Windows上叫作纤程。在c++2X以后，估计c++对协程的支持就进入了一个实用的阶段。不过真正在实际工程上应用，应该会滞后一到两年左右。毕竟IDE和相关的编译工具和调试工具的支持都需要时间。而Rust在经过反复的验证后发现至少在Rust上，协程的出现并没有带来应有的效果，或者用他们的话来说，协程和线程相比，没有优势，反而因为Rust的定位取代c++，导致和具体系统或者硬件打交道时很不方便。体现在表面上就是效率根本得不到提升。
同时，Rust对协程和本地线程的同时支持，导致了API的复杂化，同时一些具体的技术问题，比如segmented stack的无法匹配。另外，一些具体的问题也出现，比如TLS的局部存储问题。如果单纯是Rust本身是没有问题，但是一旦和c++等语言混全使用就会出现问题。
而如果解决这些问题，就势必要有一个强大的Runtime跟随着程序发布，而这恰恰又和Rust的初衷有背。其实还有不少的其它问题，这都是Rust最终把绿色线程从原生支持去除的主要原因。虽然Rust原生不支持，但不代表不可以不使用库，只要肯下成本，这个还是没有问题。
虽然是这样，还是需要介绍一下Rust中绿色线程实现的基本机制，从资料上可以看到，Rust实现协程使用的是汇编来实现的，这个和前面协程实现的机制可以对应一下就明白了。从segmented stack到后来的自身有一个栈，可以看得出Rust的协程是一个有栈协程。估计这也是最终放弃协程的一个原因，维护一个栈，对于一个新语言来说，还是有一定的成本的。特别是对于这种Gcc标准文档上都写的语焉不详的东西，对Rust的开发和维护者来说一定不是一个好梦。
所以说，RUST大佬们搞掉协程，这个魄力还是真得值得学习的！

三、总结

有没有协程，是一个语言是不是可以把多线程（或多进程）编程难度降低几个量级的一个特点，在这一点上，RUST的大佬们走了另外一条清奇的风范之路。现在不敢说这种方式是好是坏，还是那句话，让时间来检验它吧。
努力吧，归来的少年！