x01.os.11: IPC 路线图

学习的最好方法就是看代码，所以我们不妨跟着 IPC 的调用路线图，来学习学习 IPC。

从 x01.Lab.Download 下载代码后，首先进入 main.c 文件，在 TestA 中，有这么一句：Print("<Ticks:%x>", GetTicksIPC()); 其中，GetTicksIPC 就是通过 IPC 获取时间 tick 数。进入 GetTicksIPC，会看到如下代码：

    m.type = M_GetTicks;
    _SendReceive(M_Both, T_IPC, &m);
    return m.M_RetValue;    

_SendReceive 是对 syscall.s 文件中的 SendReceive 封装。调用 SendReceive 会产生一个中断而进入 SysSendReceive（在 proc.c 文件中）。顾名思义，SysSendReceive 根据消息类型，进行相应处理。现在有个问题，就是消息不止一种，每种又不止一个，处理这么多消息，需要有个生生不息的发动机。这个发动机，就是 IPC 任务，进入 ipc.c 文件，可看到如下代码：

#include "kstd.h"

void TaskIPC() {
    Message    msg;
    while (1) {
        _SendReceive(M_Receive, T_Any, &msg);
        int src = msg.source;
        switch (msg.type) {
        case M_GetTicks:
            msg.M_RetValue = g_Ticks;
            _SendReceive(M_Send, src, &msg);
            break;
        default:
            Panic("Unknown message type!");
            break;
        }
    }
}

这一下就明白了，原来，在 TaskIPC 中，先接收所有的消息，再根据消息的类型进行处理，处理后的结果由 _SendReceive 发送出去。这同微软的消息处理机制如出一辙。

TaskIPC 在任务表中，由 Schedule 进行调用。而 Schedule 则由时钟中断周而复始的调用之。生生不息的机制原来在此！

由终端进入工程目录，make 后 bochs，可看到效果图如下：

    

看来，我们的 IPC 机制，已然发挥作用了。

不过，说实话，这套消息机制，看起来优雅，但多了几次调用，效率是大打折扣的。从设计看优雅，从实际看却不理想。二者不可兼得，还是要从实际出发。也难怪 Linux 要舍弃这套近乎完美的消息处理机制，而采用宏内核了。