这个是Muxd一直用的东西
相当于一个双向PIPE
Process A open ptm得到fdm，然后fork出process B，process B open pts得到fds，然后将0,1,2都dup到fds上
那么fds就变成了process B的控制终端
后面再process B中做标准IO操作的时候就会像PIPE直接影响到fdm
终端行规程在pts之上

没什么特别要记录的，在网上search了下，贴个链接，里面会介绍一些基本概念.
http://www.cnblogs.com/Anker/archive/2012/12/25/2832568.html

终端行规程 terminal line discipline
会帮忙做规范处理

终端设备属性 ->termios

struct termios {
 tcflag_t c_iflag;
 tcflag_t c_oflag;
 tcflag_t c_cflag;
 tcflag_t c_lflag;
 cc_t c_line;
 cc_t c_cc[NCCS];
};

local flag影响驱动程序和用户之间的接口
Android上tcflag_t->
typedef unsigned int tcflag_t;

cc_t
typedef unsigned char cc_t;

control flag中很多选项标志都是用几位标识然后用或来做选择

isatty的实现，借助tcgetattr的出错机制，成功返回0；否则返回-1，带上ENOTTY

int
isatty (int  fd)
{
  struct termios term;

  return tcgetattr (fd, &term) == 0;
}

Anyway，终端IO很复杂...

创建两个PIPE，一个用于输入给协同进程，另外一个用于接收协同进程的输出
fork之后在子进程中将标准输入输出都dup到管道上

而协同进程的写法可以比较common，只用关心标准输入输出。
PIPE在写的时候如果有多个写进程，那么写的数据小于 PIPE_BUF 则不会乱序，否则自己应该就需要做同步了。

然后就是FIFO，这个就是用mkfifo创建一个file，大家都去用。
PIPE和FIFO都是半双工的

XSI IPC ->即之前System V IPC
消息队列 信号量 共享存储器

在无关进程之间共享存储段，一个是使用上面V系统shm；另外一个是使用mmap将同一文件map到他们自己的进程空间。

另外就是网络IPC了
算是复习下吧，之前这块儿看的比较多
int socket(int domain, int type, int protocol)
domain标识address family -> AF_INET, AF_INET6, AF_UNIX(AF_LOCAL), AF_UNSPEC
type标识socket类型 -> SOCK_DGRAM(UDP), SOCK_RAW(IP), SOCK_SEQPACKET, SOCK_STREAM(TCP)

一般protocol都设置为0，一般address family和type就能确认要使用的protocol

SOCK_SEQPACKET和SOCK）STREAM很像，前一个提供面向数据报文的服务，而后面这种则是面对流。
SOCK_SEQPACKET使用场景SCTP，贴一个SCTP的简要介绍。
http://www.cnblogs.com/qlee/archive/2011/07/13/2105717.html

涉及网络就必须要清楚字节序的问题，字节序与字符编码是两件不同的事情，都要想清楚的，但是要提一下UTF-8这是一种专门设计用来做网络传输的字符编码
无需关心字节序的问题，所以传输的上层数据可以用UTF-8，就不用担心local host和remote host的主机字节序不一样而导致乱序了。

但是很多协议头必须做符合TCP/IP协议的字节序规范，TCP/IP是big endian
关于Big endian和Litter endian我比较容易忘记具体的样子，但是他的出发点是低地址，低地址装的是最高有效字节那么就是big endian，否则就是litter endian。

关于socket有几个可能比较模糊的地方
connect时，也就是client端，如果fd没有绑定到某个地址，那么kernel会帮忙将其绑定到默认地址; 所以bind这件事情是Client和Server都需要做的事情，调用listen之前也一样
然后accept的时候，如果你关心对方的地址，那么提供addr(足够)和len，返回的时候就能知道。
另外UDP(SOCK_DGRAM)也可以Call connect，之后就可以直接call send/write，而不必每次都call sendto指定对端地址。

sendto中flag一般给0，如果是紧急数据给MSG_OOB

文件描述符的传输，目的是想让不同的process在不同的文件描述符中共享文件表。
所以做法上系统会这样，传输文件表指针然后放到接收端的第一个可用的文件描述符上。
这个我在linux上没找到实现，因为这个功能还是有蛮多替代方案的。

低速系统调用，也就是有信号发生会返回 errno 为 EINTR的

磁盘文件IO虽然有延时，但是这个不能算是低速系统调用

APUE介绍的低速系统调用
PIPE，终端设备，网络设备 读写
读无数据/写无空间(例如TCP卡Congestion window)

打开某些特殊文件
加记录锁的文件读写
ioctl，IPC

文件锁又叫做 byte-range locking，针对特定的文件区域，适合数据库文件
Posix标准
int fcntl(int fd, int cmd, .../* struct flock* flockptr */)
cmd -> F_GETLK,F_SETLK,F_SETLKW
F_SETLKW是F_SETLK的Blocking版本 W means wait

重要数据结构是struct flock ->
struct flock {
 short l_type;
 short l_whence;
 off_t l_start;
 off_t l_len;
 pid_t l_pid;
 __ARCH_FLOCK_PAD
};

锁定整个file的方式: l_whence = SEEK_SET, l_start = 0, l_len = 0

l_type的两类lock
F_RDLCK，F_WRLCK这两种锁的特性很像rw lock

不过与读写锁不一样的是或者这样讲
Posix.1没有规定下面这种情况: process A在某文件区间上设置了一把读锁；process B尝试在这个文件区间加上写锁的时候suspend；process C再尝试获取读锁，如果允许

process C拿到读锁，那么process B将会可能永远拿不到写锁，活活饿死

pthread里面的rw lock的实现会在这种情况下suspend掉process C的读锁请求；但是目前文件区域锁的实现我不太确定

这里看文件区域锁还是比较容易带来deadlock的
例如process A锁住F1的某个区域，然后去锁F2的一个区域，这时候F2的这个区域被process B锁住，那么process A就会suspend，如果这个时候process B过来要锁F1的这个区域
就会发生deadlock

关于文件区域锁的继承和释放
1.fork后，文件区域锁并不继承，继承了就完了，不同的process就有可能同时干同一件事情，把数据搞坏
2.close(fd)后 fd对应的文件锁就被释放了，文件锁挂在inode上，close的时候kernel会去扫描对应的inode上与这个PID相关的lock，释放掉，而并不去关心是哪个文件描述符或

者是哪个文件表，这很重要，因为lockf中并不记录fd，他们只是弱关联关系，这个很重要。
3.exec后，文件锁会继承原来执行程序的锁(fork之后拿到的lock)，如果fd带有close-on-exec那么根据第二条，这个fd对应的file上的锁都会被释放。

后面讲了STREAMS，感觉linux上用到的不多，需要在编译kernel时动态加载

IO多路转接，主要是为了实现polling既所谓的轮询
主要函数有select，pselect，poll，epoll
select也会算是低速系统调用，那么就有可能被信号打断
pselect有参数可以设定信号屏蔽集，也提供更高精度的timer

poll的方式与select有不太一样的地方，但是功能相同，epoll更适合大数据量。

readv和writev
记住下面两条就够了
一个称为scatter read(散步读)；另外一个称为gather write(聚集写)
这两个函数会面对一个buffer链表。

readn和writen
这个比较像现在Android里面socket的read和write方式，保证能read/write n byte数据，在内部做循环
我比较好奇这两个是否会处理signal，想来应该是会处理的，遇到EINTR帮忙重启就好了

我没有找到Bionic库的实现

存储映射IO
这个很重要，mmap用的很多，映射到process空间的位置在 stack以下，heap以上的部分，map完后返回低地址。

#include<sys/mman.h>
void* mmap(void* addr, size_t len, int prot, int flag, int filedes, off_t off)

prot -> PROT_READ,PROT_WRITE,PROT_EXEC,PROT_NONE
prot指定的对映射存储区的保护不能超过文件的open权限

在 flag为 MAP_FIXED的时候OS会保证分配的memory起始地址为addr，否则只是给OS一个建议。
一般建议addr给0，让OS来决定。

MAP_SHARED是说对映射区域的存储(write)会导致修改该文件。
MAP_PRIVATE则是对映射区域的操作会常见一个映射文件的副本。

后面有个例子用了lseek
使用lseek增加文件长度的方式，先lseek一个值，如果这个值大于文件本身的长度，那么下一次写就会加长该文件，并且在文件
中形成一个空洞，未写过的内容全部读为0。
mmap只能map文件的最大长度，超过的地方没办法同步到文件。

APUE讲的destroy会free空间，这件事情看起来不太对，也许是Base on实现
起码我看到的实现是没有做这件事情的。

int pthread_attr_init(pthread_attr_t * attr)
{
    *attr = gDefaultPthreadAttr;
    return 0;
}

int pthread_attr_destroy(pthread_attr_t * attr)
{
    memset(attr, 0x42, sizeof(pthread_attr_t));
    return 0;
}

Attribution有下面这些。

typedef struct
{
    uint32_t flags;
    void * stack_base;
    size_t stack_size;
    size_t guard_size;
    int32_t sched_policy;
    int32_t sched_priority;
} pthread_attr_t;

我们可以用malloc和mmap给Thread分配stack，指定stack大小和位置(低地址)

mutex属性
两个东西
1.进程共享属性，PTHREAD_PROCESS_PRIVATE or SHARED
意思是说如果这个Mutex是分配在两个进程共享的memory，然后设置为shared mutex就可以用于进程同步
2.类型属性，normal;errorcheck;recurive
意思是定义Mutex本身的特性，这里更正下前面那章提到的错误
只有normal的mutex才会在再次加锁时发生deadlock
errorcheck的会直接返回错误
recurive本身就允许，会有计数

rw lock和condition属性
只支持第一个

TLS变量
先看下TLS的位置

 * +---------------------------+
 * |     pthread_internal_t    |
 * +---------------------------+
 * |                           |
 * |          TLS area         |
 * |                           |
 * +---------------------------+
 * |                           |
 * .                           .
 * .         stack area        .
 * .                           .
 * |                           |
 * +---------------------------+
 * |         guard page        |
 * +---------------------------+

pthread_internal_t是记录线程自己本身的一些属性的变量，guard page就是线程attr上设置的防止栈溢出的扩展内存

创建TLS变量的方法
1.创建Key，这个Key是这个Process中所有Thread可以共享访问的，然后每个Thread自己去关联自己的Thread Local变量
int pthread_key_create(pthread_key_t *keyp, void (*destructor)(void*))
创建key的时候需要保证唯一调用，也就是不会有两个Thread同时调用，然后发生一些base on实现的不确定的结果，可以使用pthread_once

pthread_once的实现很简单，用mutex做互斥量保证pthread_once_t的访问，然后利用pthread_once_t做flag来调用init_routine

int  pthread_once( pthread_once_t*  once_control,  void (*init_routine)(void) )
{
    static pthread_mutex_t   once_lock = PTHREAD_RECURSIVE_MUTEX_INITIALIZER;
    volatile pthread_once_t* ocptr = once_control;

    pthread_once_t tmp = *ocptr;
    ANDROID_MEMBAR_FULL();
    if (tmp == PTHREAD_ONCE_INIT) {
        pthread_mutex_lock( &once_lock );
        if (*ocptr == PTHREAD_ONCE_INIT) {
            (*init_routine)();
            ANDROID_MEMBAR_FULL();
            *ocptr = ~PTHREAD_ONCE_INIT;
        }
        pthread_mutex_unlock( &once_lock );
    }
    return 0;
}

所以这个pthread_once_t必须是全局or静态变量
pthread_once最常用的case除了拿到TLS key外，init函数经常会使用这个，避免多线程同时调用。

然后就是thread cancel
Android Bionic库没有实现 pthread_setcancelstate(int state, int* oldstate)以及pthread_cancel()
这里thread的取消，有些是取消不掉的，例如一些blocking call，所有的取消均是需要设定一些取消点的，

有人有专门针对Android没有Thread Cancel来想办法
基本就是thread signal，在signal handler中去call pthread_exit();
or用PIPE在多路复用中break出来
http://blog.csdn.net/langresser/article/details/8531112

如果信号与硬件故障or计时器超时相关，那么信号会发送到引起事件的该线程中去，其他信号会发送到任意一个线程。
这里是说的POSIX线程模型，一般的信号都会发送给进程中没有阻塞该信号的某个线程。APUE讲的某个没有阻塞该信号的线程，其实有点模糊。

但是Linux的实现不一样，linux的thread是clone出来的，就是共享资源的独立进程，这样子其实蛮自然的，也不容易复杂。
linux中，有可能线程就不会注意到该信号，这样讲也有点模糊，总之终端驱动程序的信号会将信号通知到进程组，这样子所有的thread就会都收到信号
如果你不想所有的线程都去关心信号，那么可以使用一个专门处理信号的线程
先将其他线程的signal都pthread_sigmask SIG_BLOCK掉，然后使用sigwait在特定的线程来等
pthread_sigmask和sigprocmask很像

thread与fork
fork后的子进程会继承mutex, rw lock, condition的状态
但是子进程中只会存在一个线程，也就是那个调用fork的线程的副本，有个复杂的事情是关于上面继承下来的那些东西，子进程由于只有一个线程，没办法知道
上面那三个东西的具体状态，需要有个清理锁的动作 -->pthread_atfork(void (*prepare)(void), void (*parent)(void), void (*child)(void))
我目前不知道这个东西的使用场景，而且不容易控制。
因为一般如果我们fork后都会接execu，这样地址空间就会改变，那么这些继承的东西就没用了。

然后有谈一点关于线程IO的东西
pwrite/pread
也就是原子的进行lseek和r/w，但是这个并不能保证大家常见的冲突问题，也就是一个thread在写另外一个要读，所以这两个东西并不能解决同步的问题。

作业:
12.3 理论上函数开始时屏蔽所有信号，函数结束时恢复，是可以做到异步信号安全的。如果你只是屏蔽一些信号，那么没办法做到，因为如果有其他信号进来，你call的函数里面有一些不可重入的函数，同样不能保证是异步安全的。

12.5 fork可以在拿来执行可执行程序，现在应该就这一个Case。

int pthread_create(pthread_t *restrict tidp, const pthread_attr_t *restrict attr
     void* (*start_rtn)(void), void* restrict arg)

thread被创建的时候会继承调用线程的浮点环境和信号屏蔽字，但是该线程的未决信号集将会被清楚，
清除未决信号集这件事情应该是没有疑问的，在thread创建之前pending住的信号，不应该deliver给下一个
Ps: 线程的浮点环境指的是啥? 看来以后我应该去注意下浮点数的运算原理。

pthread相关的函数会直接返回错误码，而不会和一些system call一样，置全局errno，两种方式都有好处，一个可以讲返回值
带回的错误代码集中起来，范围缩小；另外一个非常方便，关键点在于这一类共用errno的是否真的异常是可以共用的。

pthread_create返回之前有可能新的线程就已经开始run了

启动函数 void* (*start_rtn)(void)

可以通过return给回来，也可以通过pthread_exit给
这个会存在一个地方
通过pthread_join(tid, void**)取回来

这里join的和java join是一样的功能

如果这个东西是一个很大的东西:)，那么放到heap是最好的选择，不要放到stack上了，不然线程返回这东西就没了，join取到的内存地址就变成一个无效的了，SIGSEGV就会被发出来

pthread_cancel，同一个进程可以call，提出请求终止线程

pthread_cleanup_push
pthread_cleanup_pop

线程分离，这样子线程终止后可以释放一些资源，而不用一定要其他人来join
方法有两种，新建的时候加上分离属性
    pthread_attr_init (&attr);
    pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
    ret = pthread_create(&s_tid_dispatch, &attr, eventLoop, NULL);

或者call pthread_detach(pthread_t tid)

线程互斥与同步

typedef struct
{
    int volatile value;
} pthread_mutex_t;

多注意volatile变量，这个东西理论上就是让编译器不要做优化，不要cache volatile类型的变量，
每次都去内存地址中拿，而不是寄存器/高速缓存副本，这种变量极容易被编译器不知道的人改变，例如其他线程。

静态初始化:
#define  PTHREAD_MUTEX_INITIALIZER             {0}
#define  PTHREAD_RECURSIVE_MUTEX_INITIALIZER   {0x4000}
#define  PTHREAD_ERRORCHECK_MUTEX_INITIALIZER  {0x8000}
所谓的动态初始化
pthread_mutex_init; pthread_mutex_destroy

然后就是一些pthread mutex的基本处理函数了
lock,unlock
trylock;

这个trylock需要好好理解下，尝试获取lock，如果OK，那么lock他然后 return 0; 否则也不会suspend住，而是直接返回EBUSY

pthread_mutex_destroy, 会先去try lock，然后处理掉这个mutex的值。

这里稍微提一下

int pthread_mutex_trylock(pthread_mutex_t *mutex)
{
    int mtype, tid, oldv, shared;

    if (__unlikely(mutex == NULL))
        return EINVAL;

    mtype  = (mutex->value & MUTEX_TYPE_MASK);
    shared = (mutex->value & MUTEX_SHARED_MASK);

    /**//* Handle common case first */
    if ( __likely(mtype == MUTEX_TYPE_NORMAL) )
    {
        if (__atomic_cmpxchg(shared|0, shared|1, &mutex->value) == 0) {
            ANDROID_MEMBAR_FULL();
            return 0;
        }

        return EBUSY;
    }

__likely/__unlikely函数用来告诉编译器优化代码，类似if else中最有可能or最没有可能发生的Case

mutex就有deadlock的问题，单线程，如果有代码重入重复获取锁就会deadlock，因为你走不到你unlock的地方去；另外
常见的deadlock就是lock比较多，又没有设计好顺序，这个应该从业务逻辑上就应该定义好，当然有时候有的人用的时候or改代码的时候
并没有理清这些lock的关系，是否有dependency，比较难通过借用一些编译系统来Cover住，然后改完就有bug。

然后还有一种需要设计好的是锁的粒度
太粗太细都不好
粒度太粗，lock住的东西太多，很多线程都要等lock，最后这个东西会演变成一个串行的东西
粒度太细，lock又变的太多，不停的需要lock/unlock，performance就会变差。
目前看到的Android上的很多lock都太粗。

rw锁 ->读写锁
基本理念就是读不会影响临界区发生变化
所以读模式的rw lock可以多个人占用，写模式的rw lock时能被一个线程lock

只要有写模式lock请求，那么后面的读模式lock请求一般实现是都会被Suspend住，不然因为读模式下，可以重复lock，如果不
suspend，那么写模式的lock请求有可能永远得不到相应。
rw锁一般用在 read比 write行为多的多的场景，允许多线程并发去读，单一线程去写。

然后会想到spinlock，可以去网上search看下基本概念，spinlock一般在SMP架构下会比较有效果。

mutex是一种同步机制or讲这是一种互斥机制 -> Java synchronize
还一种就是条件变量 condition.. -> wait/notify

这里有段话很好
条件变量给多个线程提供了一个回合的场所，条件变量与互斥量一起使用的时候，允许线程以无竞争方式等待特定的条件发生。

作业:
1.线程之间传递数据不要用stack变量，用放到下面这些地方的变量就好，RW/RO/ZI/Heap就没事了
4.
现在一般都是这样

    pthread_mutex_lock(&s_startupMutex);

    s_started = 1;
    pthread_cond_broadcast(&s_startupCond);

    pthread_mutex_unlock(&s_startupMutex);

会在broadcast后才unlock
否则有比较高的概率，unlock后，被其他线程将条件改掉，这个时候broadcast出去就没有意义了。
但是这种也有可能会被另外一个线程，并非wait在那里的线程改变条件值

所以 pthread_cond_wait 返回并不意味着条件一定为真了
最好是always check条件
类似这种
    while (s_started == 0) {
        pthread_cond_wait(&s_startupCond, &s_startupMutex);
    }

这里也稍微解释下Kill这个东西，kill函数，kill命令并不是字面上杀掉某些东西，kill只是在特定的时间发送信号，
具体的处理取决于信号本身和信号的处理方式。

信号的处理方式:
这个有点类似Java Exception的处理方式，catch住or往上throw

APUE讲的信号处理方式有三种
1.忽略，SIGKILL/SIGSTOP不能忽略；一般如果Process自己不管的话，应该会走到系统默认的处理流程中，所以不能忽略这件事情是系统自己就会保证的。
2.捕捉信号，例如SIGCHLD,一般parent会call waitpid取子进程终止状态，避免他处理Zombie状态。
3.执行系统默认动作

我感觉1和3可以归为一类吧，只是有些signal没有系统默认动作，然后就跳过去了。一般的系统默认动作也就是终止进程。

SIGKILL/SIGSTOP不能被忽略的原因我觉得讲的不错，提供超级用户终止进程的可靠方法，不然后续有可能进程的行为是未定义的.

signal函数定义:(

void (*signal(int signo, void(*func)(int)))(int);

这个C函数的声明有点难看懂

APUE讲signal的语义与实现有关，所以建议大家都用sigaction

不过我看了下Android Bionic下的实现，分别包含BSD以及SYSV的版本，但也都变成了sigaction，所以一般在C库中就保证了这一点，也就无所谓了。

static __sighandler_t
_signal(int  signum, __sighandler_t  handler, int  flags)
{
    struct sigaction  sa;
    __sighandler_t    result = SIG_ERR;

    sigemptyset( &sa.sa_mask );

    sa.sa_handler = handler;
    sa.sa_flags   = flags;

    if ( !sigaction( signum, &sa, &sa ) )
        result = (__sighandler_t) sa.sa_handler;

    return result;
}


__sighandler_t bsd_signal(int signum, __sighandler_t handler)
{
  return _signal(signum, handler, SA_RESTART);
}

__sighandler_t sysv_signal(int signum, __sighandler_t handler)
{
  return _signal(signum, handler, SA_RESETHAND);
}

exec函数会讲信号处理方式还原为系统默认，这个应该毫无疑问，exec后地址空间就不一样了，保留之前的捕捉函数也是无意义的；在这之前是有意义的，我的意思是说fork后exec之前。

后面有列一大堆是否可以重入的函数，不太想记，然后讲到了malloc
我想不能重入的函数无外乎两种类型
one: 自己有maintain一些全局or static变量 --> malloc 维护分配内存时static heap linklist
two: 函数参数里面有引用之类的，会影响调用者的情况。

然后我看到这个立马就想到了线程安全，malloc是线程安全的麽?
去看了下Bionic的实现，然后就又看到下面这个名字 Dong Lea，马上就会想到Java Concurrent库，看到这个你直接就会有想法，Bionic里面这个malloc肯定是线程安全的；
有时候被这些东西搞的很累，比较烦他，而且Bionic里面用的malloc的那个实现版本(aka dlmalloc)我又没看懂:(，只好去网上search了一下，有个人做过实验，有些结论还是可以参考的
http://www.360doc.com/content/12/0420/23/168576_205320609.shtml

总的来说，这个东西取决于C库实现，我想Bionic和Glibc都应该一样会支持两种不同的版本，然后编译的时候就可以确定是否有线程相关操作，然后在link的时候link过来不同的版本

线程安全和信号安全是两个概念

如果在线程安全的malloc中，信号处理函数中发生重入，那么应该是会发生dead lock
如果是非线程安全中，那么应该是所谓的 undefined behavior.

前面还有一个概率忘记写
早期的Unix系统，如果系统在执行一个低速系统调用(基本可以总结为blocking IO:包括IPC，File IO，ioctl)，那么如果捕捉到信号，那么系统就会中断这个system call -->EINTR, 这在当时是有理由的，而且理由看起来也合理，但是由于user有时候并不知道某些系统调用是否是低速系统调用，BSD引进了自动重启的功能，linux follow这种规则

然后有几个版本的signal函数
signal默认自动重启
_signal(signum, handler, SA_RESTART) 这是由于在sigaction中的flag为SA_RESTART，上面sysV的实现我不想多写了。
sigaction也就是可选的了。

但一般我印象中好多 read/write都是会自己判断返回值以及errno 是否为 EINTR，然后retry，因为上面这种方式依赖系统实现，需要将所有的signal都设定为SA_RESTART，那么如果有某个信号发生的时候，被他INTR的系统调用才会自动重启，不知道默认signal在注册处理行为的时候是不是如此，感觉不太好用。

alarm函数
对于很多像alarm这种函数，在设计时or使用时均应该考虑临界值的问题
alarm的唯一性，是by process的，process单例
所以如果alarm两次，那么第一次会被覆盖，怎么处理第一次未完成的情况->返回值会带回来剩余的时间
怎么取消设定的alarm
传入值为0 means cancel
总之了，这个东西设计的时候还蛮完善的

后面还有一堆有关signal的标准函数，这里也就不一一列举

作业:
1.去掉for(;;), 那捕捉到SIGUSR1就返回了，pause()只要捕捉到信号，等信号处理完时自己就会返回并带回EINTR。不晓得为啥有这种题目...
2.实现sig2str，这有点无聊了.:(不写
3.画runtime stack的样子。
4.IO操作的超时最好不要采用alarm的方式，各种原子问题，select/poll是最好的选择。
后面有好一些是要写代码的...
我略想，然后就不太愿意写了.
PS:有些东西略难...我也是有点想不清楚的样子，打算慢慢搞。

后面决定把标题改一下，顺利看完书吧...Orz.

与process关联的ID
谁execute这个process的人称为real user id，应该就是登陆时使用的user
real group id也一样.
一般在一个登陆Session中，这两个值都不会改变，但是超级用户进程可以改变
像Android中每个APK有独自的User id，然后类似rild之类的native deamon process就会尝试改变自己的user id为类似radio之类的东西。

在运行中检查权限所使用的id称为有效用户id，effective user id
然后还有有效组ID
附加组ID

一般有效用户ID == 真实用户ID， 有效组ID == 真实组ID
但是如果在可执行文件的st_mode中有设置 set-user-ID/set-group-ID
那在执行这个文件的时候 有效用户ID和有效组ID会变成文件的owner

一般有设置set-user-ID/set-group-ID的程序都会获得额外的权限

关于文件权限，有一些容易引起误解的，也还有一些我自己也没有理解清楚的

文件权限比较好理解，O_TRUNC需要文件具有写权限。

文件夹的写权限，应该就是类似能不能在其中create/update/delete文件和文件夹
文件夹的读权限，应该就是读文件夹里面的文件/文件夹列表，通常我们 ls 当前文件夹就必须具有读权限
文件夹的执行权限，这个东西听说又叫搜索位，通常我们cd XXX，就必须在当前文件夹下搜索XXX是否存在，然后就是当我们访问类似这种很长路径的文件/aaa/bbb/ccc/dd.txt
对aaa，bbb，ccc必须具有执行权限，就是搜索

一般如果具有读权限就应该就可以搜索，如果这之前有区别，就是应该是搜索的范围大于能读到的内容。
也就是之后需要知道一个Folder本身里面有写什么内容，我目前知道的是一定有当前的文件列表--> TODO: 看情景分析 or 去看下 ls 的实现，ls里面有比较多参数有些是需要x的有些是需要r的，例如 ls -l如果没有执行权限就只能拿到 name ,能知道是folder还是file，除此之外其他的东西都拿不到，文件本身的权限，user，group

-->linux目录中记录的应该是只有两个东西 inode & name.这与文件系统的实现有关。

另外增删文件都需要WX权限

另外内核对文件操作权限的判断顺序...如果是owner就会看owner权限，group权限就不会看了，如果在group中则others也就不看了，这个逻辑上正常，而且可以想一下kernel的实现，一定是if-else的判断出结果后直接返回。

这里就要提如果新建文件/文件夹的时候文件夹的owner user id和group id是谁
user id会是process 有效用户ID
group id可以有两种选择父folder的group id；or process有效组ID
linux中根据文件系统的不同有的可以在mount fs的时候选择

文件长度: st_size
lseek到文件末尾之后的空间，会照成文件空洞
文件长度会+空洞的大小，但是这些空洞未必会占用磁盘空间。
du 命令可以看磁盘空间大小

符号链接和所谓的硬链接完全是两回事，建议细读4.14，不要去上网search类似我这种自己记录给自己看的blog...:(

这章内容比较多而且杂，主要是stat中的每个参数的意义，需要思考想清楚的东西也比较多，有比较多关于文件操作的System Call

作业开始:
之后只写有点意义的题目，无意义的也没什么可以写的pass
4.1 stat和lstat的区别，stat基本不会关心是否是S_IFLNK(符号链接)，应该是看到S_IFLNK会往下去找真正的File，然后拿到属性值
而lstat旁道S_IFLNK则会直接返回。第一次看到这样的函数设计怪怪的，我的初始感觉是反的。我觉得stat是一个common的设计，不会针对不同的File类型来做一些区别。Orz...最后不是。

4.2 umask 777意味着rwxrwxrwx全部变没掉，但是这也没关系，不知道出题人的意思

4.5 目录和符号链接的长度不可能为0，目录创建出来就会包含. 和 ..而且 . 的inode指向自己本身会占磁盘空间，符号链接肯定也是不能为0的，其中有存指向的链接path

4.6 这个有点意思，后面贴代码

4.7 这个看了下答案，没看懂>为什么kernel默认的创建文件赋予的权限“可能会，也可能不会”受unmask的值的影响?

4.8 du df的区别...

4.9 ~ 后面的题大概看了下，不想写了，好多细节...

#define offsetof(TYPE, MEMBER) ((size_t) & ((TYPE *)0)->MEMBER )

宏功能：获得一个结构体变量成员在此结构体中的偏移量。

1. ( (TYPE *)0 ) 将零转型为TYPE类型指针;
2. ((TYPE *)0)->MEMBER 访问结构中的数据成员;

3. &( ( (TYPE *)0 )->MEMBER )取出数据成员的地址，即相对于0的偏移量，要的就这个;
4.(size_t)(&(((TYPE*)0)->MEMBER))结果转换类型，size_t应该最终为unsigned int类型。
此宏的巧妙之处在于将 0 转换成(TYPE*)，这样结构体中成员的地址即为在此结构体中的偏移量。

这里主要还是利用了 '->' 这个符号的功能，编译器解析这个符号的时候应该就是通过偏移量取值，所以这里先定义好取值规则(TYPE*)然后利用偏移量取值反向再取地址，再然后因为起始地址是0，取回的地址就变成了真正的偏移量。
还有一个知道member求整体的Ptr的Marco应该也蛮好用，括号比较多，我没头去看具体实现了...

#define container_of(ptr, type, member) ({ \
const typeof( ((type *)0)->member ) *__mptr = (ptr); \
(type *)( (char *)__mptr – offsetof(type,member) );})

宏功能：从结构体（type）某成员变量（member）指针（ptr）来求出该结构体（type）的首指针。

(2)
有讨论一些东西，没有搞清楚，贴在这里以后有心力了再看，在看Rild，然后pthread在做线程同步的时候需要先lock，也许大家都是这样做，也一直这样做，但是突然就想到之前Java的时候讨论过的东西为什么wait/notify 一定要在一个synchronize block中，当然你可以讲，如果不会有exception抛出，你也还可以讲wait本来就会先释放lock然后把当前的thread放到Object waiting thread pool中然后挂起当前线程，实现就是这样子，但是从设计来讲，原因我没有想的特别清楚，如果不去lock，是不是因为wait/notify本身有很多操作没办法做multi thread...

然后就是关于select的一些辅助的Marco，类似FD_SET，FD_ZERO之类的，简单讲就是一个long数组，每个元素的每个bit代表一个fd，然后做set，clear之类的动作，最大不能超过那个1024

今天先到这里，写个序，明天正文...Orz

(3)
继续讨论东西
有人为了在C++中作出类似Java可以自动释放内存的东西，也就是所谓的智能指针，Android有帮忙实现strong pointer/weak pointer，他的大概意思就是用一个第三者来看住当前new出来的object，采用的方式一般是引用计数，这种方式也许在Design Pattern中有专门的名字。一般利用编译器对这个第三者做自动释放的时候去检查计数器，看是否能释放他看管的object，C++里面编译器会自动去call ~Constructor就例如局部变量。

有一些复杂的Case，就算是交叉引用了，Strong Pointer/Weak Pointer就是为了解决交叉引用的问题，从语义上讲父Object引用子Object，用SP，反过来用WP
只要SP为0，就可以释放Memory

今天大家有讲Java的WeakReference，SoftReference，我就含糊了，我以为这东西和上面一样。
Java的WeakReference，SoftReference跟上面讲的完全不一样，由于没分清楚，混淆了。JVM就会处理引用交叉的问题，JVM处理引用交叉可以使用类似有向图，如果呈环状而且环中的任意点都没办法到GC Roots(VM stack中的Reference/static reference/JNI reference)，那么就都GC掉应该也没问题。
所以Java中的所谓的WeakReference/SoftReference跟SP/WP不一样，Java中普通赋值的reference都是强可及的Strong Reference。
WeakReference只是用来关心下那些将要被回收却没有回收的Object，一旦被GC Thread扫到就会被释放。
而SoftReference是JVM对Object的Cache，只要内存足够不会被释放。

贴一个讲Android SP/WP的链接，之前有印象看过。
http://blog.csdn.net/luoshengyang/article/details/6786239

(4)
Keep Thinking...
某人让我写一个处理字符串的函数，30min， 我怎么也不能让他失望的，是吧~无论11点多的时候我头有多晕，我很开心的在那里写，很直白的讲，我自己用的本是个游戏机，没啥好环境。用C写了个，然后跑出来的结果出乎预料，我想可能是长时间指手画脚惯了~仔细想了下一些文件操作

然后仔细看了一下二进制文件和文本文件，这也是纠正之前的一些疑惑。
基本概念是:
我自己感觉文本文件和二进制文件没啥区别，文本文件就是有明确普通解码方式的显示字符的文件，可以理解说文本文件也是一种二进制文件，只不过这个二进制文件的解码方式是固定好的(ASCII/UTF-8之类)

然后就是读写文本文件时在Windows上有一些转换，写的时候会在\n前面自动加上\r，读的时候反过来，Linux则没有区别。

有一件事情是要明确知道的
像printf之类的东西，帮助我们输出的，其实我们往printf里面塞的是 int 值，这是一个二进制的值，但是我们从stdout中看到的则已经变成了字符，一定有人帮忙做了转换.
我原本以为printf会是检查目标文件，如果目标文件为二进制则直接输出原本的值，如果目标为文本文件就输出对应值的字符

这种理解是错的，不同的输入输出函数带来了不同的结果
类似printf这种格式话输出函数，会把输出内容按照字符以默认的编码方式encode放入文件，所以那个文件里面写的值已经是真实值的一种显示方式(字符)了
然后scanf这种函数在读的之后，也会把字符转换为对应的值，一般ASCII就直接 -0x30了

像read/write这种function他们不会做任何转换，直接就把值放进去了，所以你用文本文件打开的时候，按照默认的decode方式来解析他的时候会发现是乱码。

这个东西与文本文件二进制文件没有关系。
不知道是不是我自己很弱，现在才知道这个东西。

作业终于开始:
3.1 这章主要讲文件Unbuffered IO，这里的unbuffered是指userspace没有buffer来缓冲，kernel一定还是有缓冲的，一般userspace的缓冲做在标准C lib中
另外像Android这种架构Java layer会做缓冲(BufferedInputStream/BufferedOutputStream, 默认是8K)
Java layer的缓冲可以减少 JNI 调用次数
C lib缓冲可以减少 system call 的次数

3.2 自己实现dup2
不能用fcntl那就只能用dup了
这里是想要让做题的人知道，kernel对进程文件描述符的分配原则是 "取最小的没有使用的"
所以用dup实现Mydup(fd1, fd2)
1.fd2 < fd1: close fd2; dup(fd1)得到的值就是fd2
2.fd2 = fd1: 直接return fd1
3.fd2 > fd1: 那就只能无限dup了，直到返回值为fd2，然后close掉 fd1 ~ fd2-1
这里需要对文件描述符表，文件表，inode之类的概念熟悉。

3.3
这里主要是要说文件表项的分配，每次open kernel都会分配新的文件表项，dup的作用就是拿到另外一个文件描述符指向相同的文件表项，但是每支文件只有同一份
inode。
fd1，fd2会指向同一份文件表项
fd1，fd2，fd3的文件表项会指向同一份inode
fcntl 作用于fd1，F_SETFD用来设定 close_on_exec 标志这个东西是在文件描述符中的，所以只会影响fd1
如果是F_SETFL则会影响fd1, fd2文件状态标志都放在文件表中。

3.4
dup2(fd, 0);
dup2(fd, 1);
dup2(fd, 2);
if (fd > 2) close(fd);
这个东西的作用应该就是重定向标准输入输出和错误输出到fd.

3.5
没什么重要的，shell命令一定是从左往右解析执行的

3.6
虽然是append方式打开，这个东西是针对写，lseek可以自己选定读取位置。
write函数是否是会每次先lseek到文件尾部?然后再写，这样之前lseek的设置就无效了
小东西验证。

后面贴下代码
append会影响每次write，只要是O_APPEND打开，每次write都会添加到文件末尾。

Done

userspace从0~0xC0000000，kernel space(0xC0000000~0xffffffff)的样子跟这个差别比较大，那边分vmalloc/kmalloc还有类似high memory的概念，这里主要贴出userspace，可以看一下RO，RW，ZI，Heap的位置，顺便提一下整个linux virtual memory其实都可以分为两部分: anonymous memory/mapped memory，像RO就是mapped memory，RW开始是mapped memory，只要有人改变初始值，那就会变成anonymous memory，ZI，Heap，Stack这些都是anonymous memory，与函数调用相关的主要是stack -->stack的地址是向低地址增长的，栈底在高地址，栈顶在低地址

然后介绍两种常用的函数调用约定，一种是C语言默认的函数调用约定 __cdecl; 另外一种是PASCAL默认的调用约定 __stdcall

这两种都是从右到左将参数压栈，然后再push ebp; mov ebp, esp; 再然后压入函数局部变量，不一样的是cdecl是由caller function将函数参数出栈，stdcall是由callee function将函数出栈。

这两种方式各有好处，慨括讲一下cdecl的话每个调用者都必须去做pop stack的动作，code size会变大；stdcall则在callee function本身来看会比较单纯

但是这种类型比较难从编译器的角度来支持变参函数。

变参函数都是cdecl

可以玩一下这样的函数...

 1#include <cstdlib>
 2#include <iostream>
 3
 4using namespace std;
 5
 6void foo(int cnt, )
 7{
 8    cout << "start foo" << endl; 
 9    int* p = &cnt;
10    for(int i = 0; i < cnt; i++){        
11        cout << *(++p) << endl;
12    }
13    cout << "end foo" << endl;
14}
15
16int main(int argc, char *argv[])
17{
18    int a = 1, b = 3, c = 5, d = 7;
19    void (*functest)(int cnt, );
20    functest = foo;
21    functest(4, a, b, c, d);
22    system("PAUSE");
23    return EXIT_SUCCESS;
24}

加一点对va_list/va_arg/va_end的说法，其实他的实现蛮灵活的

/**////stdarg.h
#define va_start _crt_va_start
#define va_arg _crt_va_arg
#define va_end _crt_va_end  

/**////vadefs.h
#define _ADDRESSOF(v)   ( &reinterpret_cast<const char &>(v) )
typedef char *  va_list;
#define _INTSIZEOF(n)   ( (sizeof(n) + sizeof(int) - 1) & ~(sizeof(int) - 1) )
#define _crt_va_start(ap,v)  ( ap = (va_list)_ADDRESSOF(v) + _INTSIZEOF(v) )
#define _crt_va_arg(ap,t)    ( *(t *)((ap += _INTSIZEOF(t)) - _INTSIZEOF(t)) )
#define _crt_va_end(ap)      ( ap = (va_list)0 )

记录一些关于系统总线与CPU“位数"的基本概念

通常所说的CPU的位数，32位or64位CPU，指的是ALU(算术逻辑单元)的宽度，也就是这个ALU处理数据的基本单元的宽度
所以数据总线基本会和ALU宽度相同(有例外，这个我没想清楚工作原理) -->应该是可以新加一些Module来做转换。
而地址总线则是CPU寻址的能力，一个是怎么去寻址，一个是寻到地址后，地址中内容的宽度(当然这个宽度跟地址类型(byte，short，int)有关，但送给CPU的时候一般是单位次数送数据总线的宽度的数据)，地址总线决定CPU能访问的Memory的范围。

8086是16位ALU 20位数据总线寻址1M
每次CPU送出的地址都是16位，然后加上段寄存器作为最高4位