梳理了下需求，大体如下：
- 进程（Process）。进程是Erlang中一个虚拟的运行单位。既不是操作系统的进程，也不是线程，而是比线程更加轻量的单位，更接近于协程。
- 命名进程（NamedProcess）。命名进程的好处是，你可以向一个不知道进程ID的进程发送消息。由于进程可能会宕掉（crash），进程ID可能会发生变化，所以在考虑了异常的环境下，命名进程降低了编码的难度（你不再需要考虑进程crash检测和重建连接的过程）。
- 进程邮箱（Mailbox）。每个进程都拥有一个自己的邮箱，其他进程发送消息到该邮箱，而进程在合适的时机从中取出消息并处理之。
- 定时器（Timer）。这个是属于最最基础的模块，用于多种用途，如超时检测等。
- 消息编码/解码（encode/decode）。将进程的请求（sync/async的函数调用）encode为网络消息流，或将网络消息流decode回进程的请求。
- 消息发送/接收（send/receive）。发送（send）指将消息（Message）发送到目标进程（Process）的进程邮箱（Mailbox）中。接收（receive）则从进程邮箱（Mailbox）取出消息（Message）。接收可以有选择性接收（selective receive），即按一定的匹配模式选择要接收的消息。
- 进程链接与监控（link/monitor）。当两个进程链接时，一个挂掉后会通知另一个进程。
- 速错（fail fast）。这关乎资源管理（Resource Management）与异常处理（Exception Handling）。Erlang的哲学是发生不可恢复的错误时就立即死掉。而进程的资源（如内存、打开的文件等等）需要被自动释放。
- 通用服务器（Server）。进程（Process）可能是一个普通的工作者（Worker），也可以是服务器（Server）。通用服务器架构实现了一套高可靠的服务器模型。
大致想象了下实现，已经基本有谱。
- 7楼 陆仁 2012-12-04 00:47发表 [回复]
 - 期待了好久
- 6楼 starcbh 2010-08-17 22:17发表 [回复]
 - 同zeusever所问，如果调度？程序员自已切换就太离谱了。。
- 5楼 zeusever 2009-05-27 10:22发表 [回复]
 - 其实最困难的是SIP（Software Isolated Processes）调度问题。在C
中要暂停当前运行的系统线程是非常困难的。如此就无法实现对SIP的主动调度。只能等待SIP内部主动交出对native thread的所有权。所以这样一个系统就更类似于一种协程，需要SIP的编写者小心的去设计调度问题。erlang由于使用的是虚拟机，有自己的软件栈而不是使用的C栈，相对这样的SIP调度就非常容易实现。基于前面同样的原因erlang是不允许直接链接C库，如允许必然损害erlang的并发特性以及可靠性。
- 4楼 ciaman911 2009-05-26 00:06发表 [回复]
 - 我觉得你的需求似乎少了一些东西,首先erlang的所有进程是在一个虚拟机上下文里面工作的,如果是在单一机器上的话,也就是一个虚拟机进程就是一个超级守护进程,你上面所列出来的只是erlang 环境中的多进程运行时候的觉大部分特性,但是C 本身是单线程内存模型,在语言级别就做不到并发,所以并发才需要一些框价来实现并发环境,其实C 的并发跟多的是依靠操作系统提供的机制来实现的,如果要用C 实现想erlang的那样的东西,可能旧需要引入系统级别的环境库,就象COM那样的(打个比方),而这样的实现就有ACE,所以C 模拟ERLANG,可能就是走ACE的路线,除非开发出一个虚拟机环境,这样C 的优点就没有发挥的余地了
- 3楼 BlueEngine 2009-04-25 11:16发表 [回复]
 - 无责任放言一句：如果以上真的靠谱并出现雏形的话，其发展有望达到ACE的地位
- 2楼 BlueEngine 2009-04-25 11:13发表 [回复]
- 拜一个～ 同时期盼透露更多相关信息
- 1楼 haonan3355 2009-04-15 03:47发表 [回复]
 - 呵呵，好久没看您出新文章啦 ：）
|
