读《C++ Primer》之返回值与缓冲区

在 Unix 系统中，通过echo $?，获取 main 函数的返回值。习题1.2，在 main 函数中，返回-1。通过上述方法查看，发现结果是255。这是为什么？

从 Wikipedia 的 Exti Status词条，可以看到如下说明：

SUS specifies that the low-order 8 bits of the status value contain the exit status;[4] this can be retrieved using the WEXITSTATUS macro in wait.h.[5] As such, on POSIX-compatible exit statuses are restricted to values 0-255, the range of an unsigned 8-bit integer.

Compile Android Source on Mac OS X

在我看来，学习 Android 的一个有效途径就是阅读它的源代码，尽管市面上有各种各样的宝典、秘籍，但能从根源上把问题讲得透透彻彻的少之又少^[推荐1]。我曾经在2010年编译并走读过它部分代码，但相比它浩瀚的代码，做的功课只是九牛一毛。

这段时间，我重新拾起丢掉的任务，计划在 MacBook Pro 走读代码，为了配合验证观点，很有必要对源代码加些注释，修改些代码。所有的这一切首先要做到将原生的 Android 源码编译通过。

图解ListView的刷新过程

ListView是 Android 应用开发中，常见的视图类组件，其普及程度差不多与 HTML 中的Table一样。此类组件的本质是将数据，也就是Model，表现出现，但其本身不负责维护数据，属于“来料加工”。

那么ListView又是怎么获得数据渠道呢？答案就是Adapter，其顾名思义就是“适配器”。就像笔记本加入市电，需要用电源适配器一样，原始数据不大可能直接显示给用户，就需要一个数据适配器，转换成视图所支持的样子。

到这里，数据已经可以展现给用户了，但是还面临一个问题，即如果数据更新了，视图能不能将新数据替换旧数据？在 Android 中，掌控数据、充当 Controller 角色的是Activity，它应该是知道数据有变化的，同时，它还持有 View和Adapter。

遭遇git send-email和svn patch

长假后的第二天，上头传来了加强代码质量的“旨意”，目标是每一次代码提交都得先给 leader 审核。那么如何落实呢？先导出 patch 文件，然后 email 给责任人，收到对方明确的通过意见后，才能执行 commit。–这种方法似乎很类似 Linux Kernel 的情形，我倒也不反对。

但如此一来，审核环节就成了一个瓶颈，整个的开发行为也就变得串行化。最后方案初步调整为，在 SVN 仓库新开一个分支，专门用于开发人员的提交，开发人员修改后发出 patch 给同事审核，通过后提交到分支。再由 leader 逐个审核分支提交，将认为 OK 的提交合并到主干。这样，主干上始终保持着被认为是合格的代码。

读CSAPP之进程、用户和内核模式

进程是一个执行中的程序的实例。系统中的每个程序都是运行在某个进程的上下文（context）中。上下文由内核维持，由程序正确运行所需要的状态组成，包括通用目的寄存器、浮点寄存器、程序计数器、用户栈、状态寄存器、内核栈和各种内核数据结构。

进程提供给应用程序两个关键抽象，其一是一个独立的逻辑控制流，好像应用程序独占地使用处理器；其二是一个私有的地址空间，好像应用程序独占地使用存储器系统。

从程序员的角度，进程总是处于三种状态之一，其一，运行，要么在 CPU 上执行，要么在等待被执行并最终会被内核调度；其二，停止，当收到 SIGSTOP（非来自终端的停止信号）、SIGTSTP（来自终端的停止信号）、SIGTTIN（后台进程从终端读） 或 SIGTTOU（后台进程向终端写） 信号时，进程即停止，并且保持到停止，直到收到一个 SIGCONT（继续进程如果该进程停止） 的信号，这时，进程再次运行；其三，终止，进程永远停止。