移植之乱谈

昨天有一个博友回复，说他已经完成了android系统在windows上的移植，其中比较难的是binder系统的移植。下面是两个demo网址，我看了后倍有感触。

http://v.youku.com/v_show/id_XMzIwMDkxOTQ4.html
http://v.youku.com/v_show/id_XMzIwNzI2NTg4.html

这才是真正有技术含量的移植啊！

从做android开始，听到的最多的就是移植+merge了。但总感觉都是：

1 简单的把人家做好的，放到新的平台上，然后测试，修改。完完全全的改bug。甚至都不需要对系统，程序结构有什么深入的了解。

2 做linux驱动更是这样，到处去改参数，调板子。（个人感觉都被硬件绑架了..）。

什么后果？居然很多人一年都写不了几行代码！！！我知道google有一个美女程序员，每天都要花4个小时来写代码，没有什么别的特殊目的，就是为了保持脑子的灵活。

另外，那些刚工作的人，改改bug就完成工作，而又不写代码，让他们误以为程序员就是这样工作的，结果不去花时间研究系统（放着linux内核，android系统这种高质量，高复杂度的优秀源码不看。说实话，代码量不超过10w行以上的同志，真的怀疑能否看懂代码的真正意图，所以google校园招聘的时候，似乎对代码量有一定的要求），

【这里也请那些培训学校的老师们，稍微注重下教育质量，培训方法。】

我心目中的移植，是应该建立再对当前平台和目标平台的一个深刻认识上，再加上对要移植代码本身，程序结构得深入了解上才能做的。看看上面博友的移植，如果只会改几个bug，何年何月才能将android系统移植到windows上呢？

下面是我之前做的一份关于完成端口到linux平台上的移植的设计文档。这个设计由于各种原因，最终没有被讨论过，也没有（永远不会）被采用。

<strong>                                                   完成端口在Linux平台下的实现

一 说明</strong>

Windows下的完成端口模式是一种真正的由操作系统来实现的“异步IO”，应用程序等待完成通知即可。

在面向对象的网络库中，包括ACE, ASIO, LibEvent, SPServer等开源公共库中实际有类似的模块。一般将完成端口模型称之为Proactor模型，而select的方式称之为Reactor模型。

简单来说，在Reactor模型中，系统通知你可以干什么，然后应用程序去做对应的事情（例如send，recv，accept等）。以发送为例，流程大致如下：

1  用户注册回调事件

2  Reactor等待select返回，然后调用回调

3 用户在回调中继续发送操作（非异步IO）

而在Proactor模型中，系统通知你什么已经干完了（例如上一次send完成了，recv完成了，accept完成了）等，仍以发送为例，流程大致如下：

1  用户注册回调，发送数据（异步IO）

2  Proactor检测发送完成事件，然后调用回调

3  用户在回调中继续发送操作（异步IO）

从流程上看，似乎没有区别。而关键点就在于IO是否为异步。Reactor模型一般是非异步的，而Proactor由于能检测完成事件，所以IO是异步的。

在Linux平台上，由于系统并没有支持异步IO，所以我们必须用Reactor的模式去模拟一个Proactor模式。大体流程如下；

1 用户注册回调，发送数据（非阻塞IO）

2 构造一个完成事件，记录发送的结果，并添加到完成事件队列

3 Proactor检测完成事件队列，然后调用回调

4 用户继续发送数据（非阻塞IO）

从上面可以看出，在Linux下Proactor的实现关键是自己构造一个完成事件队列，并处理相关入队和出队的操作即可。这种实现方式与windows完成端口是一致的。

从已知的资料来看，Proactor模型本身没有设计缺陷。我们将参考Windows下的完成端口的原理和用法来实现一个Linux平台下的完成端口。

 

<strong>二 设计细节</strong>

与完成端口相关的有线程池，完成端口句柄，和完成事件队列。

1 完成端口句柄：将与一个epoll句柄相对应

2  线程池：调用GetQueuedCompletionStatus从完成事件队列中取事件

3  用户调用IO操作，将事件加入完成队列

<strong>2.1 事件入队</strong>
先讨论事件入队的操作。有两种明显的方式来完成。

这里所有的socket或者别的文件句柄必须都是非阻塞的。

<strong>1, 真正的异步IO</strong> 

要实现真正的异步IO，需要有一个线程池来完成实际的IO工作，并且还需要有一个IO请求队列来保存用户提交的IO操作请求。在Windows平台下，这个线程池和队列是位于操作系统内部的。而在Linux平台上得自己创建相关组建。

工作流程如下：

1 用户发起IO操作，内部创建一个IO请求，并加入到请求队列

2  内部线程从请求队列中取出请求，完成实际的请求，并将请求结果加入到完成端口的完成事件队列

这种方式的优缺点有：

1  优点，很大程度上的异步IO。（其他的优点暂时未想到）

2  缺点：实现难度较大，而且资源消耗比较多

<strong>2. 利用非阻塞模式构造的伪异步IO</strong>

在这方式下将在用户调用的IO函数中直接完成实际的IO操作，只不过不阻塞罢了。这种方式可以不需要IO请求队列，不需要线程池。

考虑目前的并发数量，暂时用方式2来实现。

 

<strong>2.2 一些不能完全实现的地方</strong>
Windows下有些用法在Linux没有合适的模型对应，包括：

1  AcceptEx对应的先创建socket以供AcceptEx使用的方法

2  GetAcceptExSockAddr

实现过程中，将尽力保证接口的一致。

<strong>2.3 涉及的内容</strong>
模块上，可能包括：

1 完成端口相关函数和类设计

2 已有windows下的线程池到Linux平台下的移植

3 Socket相关库的修改与异步IO配套功能的增加

性能考虑方面，目前可以想到的包括：

1 池的和自旋锁的使用

2 GetQueuedCompletionStatus函数的内部实现要考虑使用刚完成工作的那个线程来继续工作，以避免不必要的线程切换

3 同理，PostQueuedCompletionStatus函数内部要避免触发所有线程来竞争一个事件的出队

回想当时做这个移植，花了很多时间来调研完成端口的实现机制，来研究proactor和reactor的区别，来研究linx平台的特性。考虑到完成端口是Win平台最有效率的IO操作，那么在linux平台上实现自然也得考虑效率方面的问题。

虽然最终没有实现该设想，但却极大加深了对以上知识的认识，对以后的工作有非常大的帮助。

作为本篇的结尾，希望大家认真对待工作，从简单的移植工作中去发掘背后那块绝大的金矿，以提高自己的价值。