怎么会想到这个问题，出发点是来自提出一个更通用的多线程架构的问题。其实这个问题我现在讨论有点过早，因为至今还没仔细研究过go和erlang，不了解多线程编程的现状。但总归在这个blog的小小圈子里，随便抒发几句应该是问题不大。
其实我的想法是很简单的，就是想增加一个 “任务” 的概念。这个必然很多语言很多系统已经提供了，我为什么还要提。我主要是感觉，现在的多线程编程，还有网络编程，每个程序都自己定义一套多线程管理、进程池、线程池、网络连接池、数据库连接池等等概念。虽然有库函数，不必每次从头造轮子，但每个程序一份几乎完全雷同的管理机制，绝对是有问题的。
况且，现在的操作系统，除了CPU占用这一点实现了“抢占”之外，其他的系统资源仍然是依赖程序间的谦让协作的。我前几天发的帖子，就是因为adb的一个bug，导致占用了过多的系统连接，导致其他程序无法使用网络。同样的例子，臭名昭著的迅雷，因为过量占用连接数导致你根本无法上网。虽然最近迅雷提供了种种功能，他会检测你有没有使用浏览器，他会检测某些著名的端口（对应各大著名网游），确定你是不是在打游戏，等等，来谦让地给你腾出一些网络带宽。但问题是，这样看来，是不是太委屈迅雷大哥了。虽然霸占过多网络资源是他的不对，但是研究到底应该使用多少资源，并不是一个应用程序能够做到的事情（迅雷也只是经验性的猜测，你自己写的网游、小众的网络服务，他一定是无法猜测到的）。
参考CPU抢占的系统设计，其实资源抢占完全也是可以做到的。还可以参考虚拟内存的方式，给每个应用程序足够巨大的虚拟资源空间，并使用工作集、缺页调度等机制，调度所有的资源。这样擅自开辟了大量网络连接的服务(如adb)，也不会导致系统无法打开更多的网络连接，霸占了大量资源的迅雷，也无法阻止其他程序连接网络（因为有工作集的限制）。操作系统可以根据资源使用的活跃程度等因素调度资源，例如当其他程序都不使用网络时，就可以让例如迅雷这样开辟了过多连接的程序拥有更大的工作集，保证系统资源的最大化利用。
好吧，话说到这里已经扯开去了。前面提到的多线程管理的机制，其实跟这个资源抢占的机制没有任何关系。只是因为思路飘忽扯到这里来了。说回那个多线程管理的问题，也是一样的，我希望提供一种机制说明任务的并发逻辑（可能要使用新的语言，至少C语言无法表达并发逻辑这种概念），然后要使用什么样的并发度，这个决定让系统来做。因为系统有多少内存资源，有多少CPU资源，这些事情本不该是应用程序该知道、该负责的事情。尤其是，跟本身的应用程序一起，系统里还有哪些其他的程序在跑，他们对内存和CPU的消耗如何，更加不是应用程序的职责范围能知道的。但是决定一个任务的并发度，必须从系统级思考问题。因此把并发逻辑列清楚之后，让系统去决策如何并发，才是最良好的策略。我不知道go语言或者erlang这些传说有着高度并发支持的语言是否已经做到这样，如果是这样的话，我就再次后知后觉了；不过作为一个思考练习，也是挺好的～(热烈欢迎评论拍砖=)
好吧，把资源抢占和这个多线程管理机制综合到一起，就变成了更系统更完善的系统管理机制。因为并发度不仅要考虑内存CPU，也要考虑硬盘、网络、设备等等等等。把所有的资源使用频率整合统筹调度，就能得到最优化的系统，当然这个多维度的最优问题，也将成为一个巨大的算法难点。也正是因为想到这里，我才感到格外兴奋。
说实话，即使用十年时间去开发出来这样一个系统也不会太迟。但要做到一点，就是对市场现有产品的兼容性。如果能运行java虚拟机，或者能兼容linux系统调用（也就是说新系统在linux的基础上修改得到，说实话我觉得这是一个靠谱的打算），或者至少旧有的程序代码通过编译能够运行在新的系统上，并且仍能体现系统的优越性，那么新东西做出来就不会没有市场没有价值。
不过我真的要跳这么个大坑么。。还是仅仅满足于YY然后坐看系统更替风云变幻？说实话，自己感觉暂时能力有限不足以完成伟任呢，或者说过于浮躁也有可能。暂时先记录一下吧，也许明天就会自否命题了呢囧|||
有时间先去研究下go和erlang哈哈:)
PS. 还有一个关于通用缓冲区设计的思考练习，目前正在开发和实验中，有结果了一定写bo！
