1.1  Wait-freedom 无等待并发

Wait-freedom 指的是每一个线程都一直运行下去而无须等待外部条件，整个流程中任何操作都能在一个有限的步骤内完成，这是最高的并发级别，没有任何阻塞。

 结合之前原子操作部分的知识，可以简单认为能够直接调用一个原子操作实现的算法或程序就属于Wait-free，比如下面的 increment_reference_counter 函数就是wait-free的，它封装了atomic_increment这个原子自增原语，多个线程可以同时调用这个函数对同一个内存变量进行自增，而无须任何阻塞（其实也是有阻塞的，是总线锁级别）

 与此做对比，CAS类的调用就不是wait-free的，注意wait-free的原语都不能包含内部循环，CAS原语使用时通常包含在“循环直到成功”的循环内部。

 void increment_reference_counter(rc_base* obj)

{

    atomic_increment(obj->rc);

}

1.2  Lock-freedom 无锁并发

Lock-freedom 指的是整个系统作为一个整体一直运行下去，系统内部单个线程某段时间内可能会饥饿，这是比wait-freedom弱的并发级别，但系统整体上看依然是没有阻塞的。所有wait-free的算法显然都满足lock-free的要求。

 Lock-free算法通常可以通过同步原语 CAS实现。

 void stack_push(stack* s, node* n)

{

    node* head;

    do

    {

        head = s->head;

        n->next = head;

    }

    while ( ! atomic_compare_exchange(s->head, head, n));

}

多个线程同时调用上述函数，理论上某个线程可以一直困在循环内部，但一旦有一个线程原子操作失败而返回循环，意味着有其他线程成功执行了原子操作而退出循环，从而保证系统整体是没有阻塞的。

 其实前面的原子自增函数也可以用下面的原语实现，在这种实现里，不再是所有线程都无阻塞了，某些线程可能会因为CAS失败而回绕若干次循环。

void increment_reference_counter(rc_base* obj)

{

       Int rc;

       Do {

       rc = obj->rc;

} while(!atomic_compare_exchange(obj->rc,rc,rc+1));

}

1.3  Obstruction-freedom 无阻塞并发

Obstruction-free 是指在任何时间点，一个孤立运行线程的每一个操作可以在有限步之内结束。只要没有竞争，线程就可以持续运行，一旦共享数据被修改，Obstruction-free 要求中止已经完成的部分操作，并进行回滚，obstruction-free 是并发级别更低的非阻塞并发，该算法在不出现冲突性操作的情况下提供单线程式的执行进度保证，所有 Lock-Free 的算法都是 Obstruction-free 的。

1.4  Blocking algoithms 阻塞并发

阻塞类的算法是并发级别最低的同步算法，它一般需要产生阻塞。可以简单认为基于锁的实现是blocking的算法。详细参考第五章

上述几种并发级别可以使用下图描述：
蓝色是阻塞的算法，绿色是非阻塞算法，金字塔越上方，并发级别越高，性能越好，右边的金字塔是实现工具（原子操作、锁、互斥体等）

以前一直不明白lock free是什么，后来发现原来是完全理解错了概念，lock free看到大家有的翻译为无锁，有的翻译为锁无关，其实用不用锁和lock free是不相关的，用了锁也可能是lock free，而不用锁有可能不是lock free。

一个lock free的解释是

一个“锁无关”的程序能够确保执行它的所有线程中至少有一个能够继续往下执行。

其实看我们那副图就是说你的各个线程不会互相阻塞，那么你的程序才能成为lock free的。像我们平常用的互斥锁，当有线程获得锁，其他线程就被阻塞掉了，这里的问题就是如果获得锁的线程挂掉了，而且锁也没有释放，那么整个程序其实就被block在那了，而如果程序是lock free的那么即使有线程挂掉，也不影响整个程序继续向下进行，也就是系统在整体上而言是一直前进的。

那么，不用锁就是lock free的吗，一开始就提到了，不用锁也可能不是lock free的，举个例子

在这里如果两个线程同时执行，可能同时进入while循环，然后x两次改变值之后，依然是0，那么两个线程就会一直互相在这里阻塞掉了，所以这里虽然没有锁，依然不是lock free的。

现在大家写lock free的时候一般都会使用CAS（compare and set）操作来写，因为现在很多的cpu都是支持CAS操作并作为原子操作来处理的，CAS操作一般是这样的

其实这样一个操作和乐观锁很像，并且操作简单，相应的比互斥锁的代价要小。所以现在大家都是喜欢用lock free的技术来提高系统的performance。

最后如果大家对于如何编写lock free的数据结构感兴趣的话，可以参考我后面给出的链接。

一种高效无锁内存队列的实现
无锁队列的实现
锁无关的(Lock-Free)数据结构
An Introduction to Lock-Free Programming

在一个TCP套接口被设置为非阻塞之后调用connect,connect会立即返回EINPROGRESS错误,表示连接操作正在进行中,但是仍未完成;同时TCP的三路握手操作继续进行;在这之后,我们可以调用select来检查这个链接是否建立成功;非阻塞connect有三种用途:
1.我们可以在三路握手的同时做一些其它的处理.connect操作要花一个往返时间完成,而且可以是在任何地方,从几个毫秒的局域网到几百毫秒或几秒的广域网.在这段时间内我们可能有一些其他的处理想要执行;
2.可以用这种技术同时建立多个连接.在Web浏览器中很普遍;
3.由于我们使用select来等待连接的完成,因此我们可以给select设置一个时间限制,从而缩短connect的超时时间.在大多数实现中,connect的超时时间在75秒到几分钟之间.有时候应用程序想要一个更短的超时时间,使用非阻塞connect就是一种方法;
非阻塞connect听起来虽然简单,但是仍然有一些细节问题要处理:
1.即使套接口是非阻塞的,如果连接的服务器在同一台主机上,那么在调用connect建立连接时,连接通常会立即建立成功.我们必须处理这种情况;
2.源自Berkeley的实现(和Posix.1g)有两条与select和非阻塞IO相关的规则:
A:当连接建立成功时,套接口描述符变成可写;
B:当连接出错时,套接口描述符变成既可读又可写;
注意:当一个套接口出错时,它会被select调用标记为既可读又可写;

非阻塞connect有这么多好处,但是处理非阻塞connect时会遇到很多可移植性问题;

处理非阻塞connect的步骤:
第一步:创建socket,返回套接口描述符;
第二步:调用fcntl把套接口描述符设置成非阻塞;
第三步:调用connect开始建立连接;
第四步:判断连接是否成功建立;
A:如果connect返回0,表示连接简称成功(服务器可客户端在同一台机器上时就有可能发生这种情况);
B:调用select来等待连接建立成功完成;
如果select返回0,则表示建立连接超时;我们返回超时错误给用户,同时关闭连接,以防止三路握手操作继续进行下去;
如果select返回大于0的值,则需要检查套接口描述符是否可读或可写;如果套接口描述符可读或可写,则我们可以通过调用getsockopt来得到套接口上待处理的错误(SO_ERROR),如果连接建立成功,这个错误值将是0,如果建立连接时遇到错误,则这个值是连接错误所对应的errno值(比如:ECONNREFUSED,ETIMEDOUT等).
"读取套接口上的错误"是遇到的第一个可移植性问题;如果出现问题,getsockopt源自Berkeley的实现是返回0,等待处理的错误在变量errno中返回;但是Solaris会让getsockopt返回-1,errno置为待处理的错误;我们对这两种情况都要处理;

这样,在处理非阻塞connect时,在不同的套接口实现的平台中存在的移植性问题,首先,有可能在调用select之前,连接就已经建立成功,而且对方的数据已经到来.在这种情况下,连接成功时套接口将既可读又可写.这和连接失败时是一样的.这个时候我们还得通过getsockopt来读取错误值;这是第二个可移植性问题;
移植性问题总结:
1.对于出错的套接口描述符,getsockopt的返回值源自Berkeley的实现是返回0,待处理的错误值存储在errno中;而源自Solaris的实现是返回0,待处理的错误存储在errno中;(套接口描述符出错时调用getsockopt的返回值不可移植)
2.有可能在调用select之前,连接就已经建立成功,而且对方的数据已经到来,在这种情况下,套接口描述符是既可读又可写;这与套接口描述符出错时是一样的;(怎样判断连接是否建立成功的条件不可移植)

这样的话,在我们判断连接是否建立成功的条件不唯一时,我们可以有以下的方法来解决这个问题:
1.调用getpeername代替getsockopt.如果调用getpeername失败,getpeername返回ENOTCONN,表示连接建立失败,我们必须以SO_ERROR调用getsockopt得到套接口描述符上的待处理错误;
2.调用read,读取长度为0字节的数据.如果read调用失败,则表示连接建立失败,而且read返回的errno指明了连接失败的原因.如果连接建立成功,read应该返回0;
3.再调用一次connect.它应该失败,如果错误errno是EISCONN,就表示套接口已经建立,而且第一次连接是成功的;否则,连接就是失败的;

被中断的connect:
如果在一个阻塞式套接口上调用connect,在TCP的三路握手操作完成之前被中断了,比如说,被捕获的信号中断,将会发生什么呢?假定connect不会自动重启,它将返回EINTR.那么,这个时候,我们就不能再调用connect等待连接建立完成了,如果再次调用connect来等待连接建立完成的话,connect将会返回错误值EADDRINUSE.在这种情况下,应该做的是调用select,就像在非阻塞式connect中所做的一样.然后,select在连接建立成功(使套接口描述符可写)或连接建立失败(使套接口描述符既可读又可写)时返回;

方法二、定义信号处理函数：

1. sigset(SIGALRM, u_alarm_handler);
   
2. alarm(2);
   
3. code = connect(socket_fd, (struct sockaddr*)&socket_st, sizeof(struct sockaddr_in));
   
4. alarm(0);
   
5. sigrelse(SIGALRM);

首先定义一个中断信号处理函数u_alarm_handler，用于超时后的报警处理，然后定义一个2秒的定时器，执行connect，当系统connect成功，则系统正常执行下去；如果connect不成功阻塞在这里，则超过定义的2秒后，系统会产生一个信号，触发执行u_alarm_handler函数， 当执行完u_alarm_handler后，程序将继续从connect的下面一行执行下去。
其中，处理函数可以如下定义，也可以加入更多的错误处理。

1. void u_alarm_handler()
2. {
3. }

#include <unistd.h>
#include <fcntl.h> 
int fcntl(int fd, int cmd); 
int fcntl(int fd, int cmd, long arg); 
int fcntl(int fd, int cmd, struct flock *lock);

[描述]
fcntl()针对(文件)描述符提供控制。参数fd是被参数cmd操作(如下面的描述)的描述符。针对cmd的值，fcntl能够接受第三个参数int arg。

[返回值]
fcntl()的返回值与命令有关。如果出错，所有命令都返回－1，如果成功则返回某个其他值。下列三个命令有特定返回值：F_DUPFD , F_GETFD , F_GETFL以及F_GETOWN。
    F_DUPFD   返回新的文件描述符
    F_GETFD   返回相应标志
    F_GETFL , F_GETOWN   返回一个正的进程ID或负的进程组ID

fcntl函数有5种功能： 
1. 复制一个现有的描述符(cmd=F_DUPFD). 
2. 获得／设置文件描述符标记(cmd=F_GETFD或F_SETFD). 
3. 获得／设置文件状态标记(cmd=F_GETFL或F_SETFL). 
4. 获得／设置异步I/O所有权(cmd=F_GETOWN或F_SETOWN). 
5. 获得／设置记录锁(cmd=F_GETLK , F_SETLK或F_SETLKW).

1. cmd值的F_DUPFD ： 
F_DUPFD    返回一个如下描述的(文件)描述符：
        ·最小的大于或等于arg的一个可用的描述符
        ·与原始操作符一样的某对象的引用
        ·如果对象是文件(file)的话，则返回一个新的描述符，这个描述符与arg共享相同的偏移量(offset)
        ·相同的访问模式(读，写或读/写)
        ·相同的文件状态标志(如：两个文件描述符共享相同的状态标志)
        ·与新的文件描述符结合在一起的close-on-exec标志被设置成交叉式访问execve(2)的系统调用

实际上调用dup(oldfd)；
等效于
        fcntl(oldfd, F_DUPFD, 0);

而调用dup2(oldfd, newfd)；
等效于
        close(oldfd)；
        fcntl(oldfd, F_DUPFD, newfd)；

2. cmd值的F_GETFD和F_SETFD：      
F_GETFD    取得与文件描述符fd联合的close-on-exec标志，类似FD_CLOEXEC。如果返回值和FD_CLOEXEC进行与运算结果是0的话，文件保持交叉式访问exec()，否则如果通过exec运行的话，文件将被关闭(arg 被忽略)        
F_SETFD    设置close-on-exec标志，该标志以参数arg的FD_CLOEXEC位决定，应当了解很多现存的涉及文件描述符标志的程序并不使用常数 FD_CLOEXEC，而是将此标志设置为0(系统默认，在exec时不关闭)或1(在exec时关闭)    

在修改文件描述符标志或文件状态标志时必须谨慎，先要取得现在的标志值，然后按照希望修改它，最后设置新标志值。不能只是执行F_SETFD或F_SETFL命令，这样会关闭以前设置的标志位。 

3. cmd值的F_GETFL和F_SETFL：   
F_GETFL    取得fd的文件状态标志，如同下面的描述一样(arg被忽略)，在说明open函数时，已说明
了文件状态标志。不幸的是，三个存取方式标志 (O_RDONLY , O_WRONLY , 以及O_RDWR)并不各占1位。(这三种标志的值各是0 , 1和2，由于历史原因，这三种值互斥 — 一个文件只能有这三种值之一。) 因此首先必须用屏蔽字O_ACCMODE相与取得存取方式位，然后将结果与这三种值相比较。       
F_SETFL    设置给arg描述符状态标志，可以更改的几个标志是：O_APPEND，O_NONBLOCK，O_SYNC 和 O_ASYNC。而fcntl的文件状态标志总共有7个：O_RDONLY , O_WRONLY , O_RDWR , O_APPEND , O_NONBLOCK , O_SYNC和O_ASYNC

可更改的几个标志如下面的描述：
    O_NONBLOCK   非阻塞I/O，如果read(2)调用没有可读取的数据，或者如果write(2)操作将阻塞，则read或write调用将返回-1和EAGAIN错误
    O_APPEND     强制每次写(write)操作都添加在文件大的末尾，相当于open(2)的O_APPEND标志
    O_DIRECT     最小化或去掉reading和writing的缓存影响。系统将企图避免缓存你的读或写的数据。如果不能够避免缓存，那么它将最小化已经被缓存了的数据造成的影响。如果这个标志用的不够好，将大大的降低性能
    O_ASYNC      当I/O可用的时候，允许SIGIO信号发送到进程组，例如：当有数据可以读的时候

4. cmd值的F_GETOWN和F_SETOWN：   
F_GETOWN   取得当前正在接收SIGIO或者SIGURG信号的进程id或进程组id，进程组id返回的是负值(arg被忽略)     
F_SETOWN   设置将接收SIGIO和SIGURG信号的进程id或进程组id，进程组id通过提供负值的arg来说明(arg绝对值的一个进程组ID)，否则arg将被认为是进程id

 5. cmd值的F_GETLK, F_SETLK或F_SETLKW： 获得／设置记录锁的功能，成功则返回0，若有错误则返回-1，错误原因存于errno。
F_GETLK    通过第三个参数arg(一个指向flock的结构体)取得第一个阻塞lock description指向的锁。取得的信息将覆盖传到fcntl()的flock结构的信息。如果没有发现能够阻止本次锁(flock)生成的锁，这个结构将不被改变，除非锁的类型被设置成F_UNLCK    
F_SETLK    按照指向结构体flock的指针的第三个参数arg所描述的锁的信息设置或者清除一个文件的segment锁。F_SETLK被用来实现共享(或读)锁(F_RDLCK)或独占(写)锁(F_WRLCK)，同样可以去掉这两种锁(F_UNLCK)。如果共享锁或独占锁不能被设置，fcntl()将立即返回EAGAIN     
F_SETLKW   除了共享锁或独占锁被其他的锁阻塞这种情况外，这个命令和F_SETLK是一样的。如果共享锁或独占锁被其他的锁阻塞，进程将等待直到这个请求能够完成。当fcntl()正在等待文件的某个区域的时候捕捉到一个信号，如果这个信号没有被指定SA_RESTART, fcntl将被中断

当一个共享锁被set到一个文件的某段的时候，其他的进程可以set共享锁到这个段或这个段的一部分。共享锁阻止任何其他进程set独占锁到这段保护区域的任何部分。如果文件描述符没有以读的访问方式打开的话，共享锁的设置请求会失败。

独占锁阻止任何其他的进程在这段保护区域任何位置设置共享锁或独占锁。如果文件描述符不是以写的访问方式打开的话，独占锁的请求会失败。

结构体flock的指针：
struct flcok 
{ 
short int l_type; /* 锁定的状态*/

//以下的三个参数用于分段对文件加锁，若对整个文件加锁，则：l_whence=SEEK_SET, l_start=0, l_len=0
short int l_whence; /*决定l_start位置*/ 
off_t l_start; /*锁定区域的开头位置*/ 
off_t l_len; /*锁定区域的大小*/

pid_t l_pid; /*锁定动作的进程*/ 
};

l_type 有三种状态： 
F_RDLCK   建立一个供读取用的锁定 
F_WRLCK   建立一个供写入用的锁定 
F_UNLCK   删除之前建立的锁定

l_whence 也有三种方式： 
SEEK_SET   以文件开头为锁定的起始位置 
SEEK_CUR   以目前文件读写位置为锁定的起始位置 
SEEK_END   以文件结尾为锁定的起始位置

fcntl文件锁有两种类型：建议性锁和强制性锁
建议性锁是这样规定的：每个使用上锁文件的进程都要检查是否有锁存在，当然还得尊重已有的锁。内核和系统总体上都坚持不使用建议性锁，它们依靠程序员遵守这个规定。
强制性锁是由内核执行的：当文件被上锁来进行写入操作时，在锁定该文件的进程释放该锁之前，内核会阻止任何对该文件的读或写访问，每次读或写访问都得检查锁是否存在。

系统默认fcntl都是建议性锁，强制性锁是非POSIX标准的。如果要使用强制性锁，要使整个系统可以使用强制性锁，那么得需要重新挂载文件系统，mount使用参数 -0 mand 打开强制性锁，或者关闭已加锁文件的组执行权限并且打开该文件的set-GID权限位。
建议性锁只在cooperating processes之间才有用。对cooperating process的理解是最重要的，它指的是会影响其它进程的进程或被别的进程所影响的进程，举两个例子：
(1) 我们可以同时在两个窗口中运行同一个命令，对同一个文件进行操作，那么这两个进程就是cooperating  processes
(2) cat file | sort，那么cat和sort产生的进程就是使用了pipe的cooperating processes

使用fcntl文件锁进行I/O操作必须小心：进程在开始任何I/O操作前如何去处理锁，在对文件解锁前如何完成所有的操作，是必须考虑的。如果在设置锁之前打开文件，或者读取该锁之后关闭文件，另一个进程就可能在上锁/解锁操作和打开/关闭操作之间的几分之一秒内访问该文件。当一个进程对文件加锁后，无论它是否释放所加的锁，只要文件关闭，内核都会自动释放加在文件上的建议性锁(这也是建议性锁和强制性锁的最大区别)，所以不要想设置建议性锁来达到永久不让别的进程访问文件的目的(强制性锁才可以)；强制性锁则对所有进程起作用。

fcntl使用三个参数 F_SETLK/F_SETLKW， F_UNLCK和F_GETLK 来分别要求、释放、测试record locks。record locks是对文件一部分而不是整个文件的锁，这种细致的控制使得进程更好地协作以共享文件资源。fcntl能够用于读取锁和写入锁，read lock也叫shared lock(共享锁)， 因为多个cooperating process能够在文件的同一部分建立读取锁；write lock被称为exclusive lock(排斥锁)，因为任何时刻只能有一个cooperating process在文件的某部分上建立写入锁。如果cooperating processes对文件进行操作，那么它们可以同时对文件加read lock，在一个cooperating process加write lock之前，必须释放别的cooperating process加在该文件的read lock和wrtie lock，也就是说，对于文件只能有一个write lock存在，read lock和wrtie lock不能共存。

1.将点分十进制字符串转换成十进制长整型数：in_addr_t inet_addr(const char *cp);       in_addr_t 即long型，参数cp表示一个点分十进制字符串，返回值是十进制长整型数。 

2.将长整型IP地址转换成点分十进制：char *inet_ntoa(struct in_addr in);   参数in是一个in_addr类型的结构体，这个结构体在man 7 ip中查得到：
  struct in_addr{
     uint32_t s_addr
  };
inet_ntoa返回的是点分十进制的IP地址字符串。 

3.主机字符顺序和网络字符顺序的转换：计算机中的字符和网络中的字符的存储顺序是不同的，计算机中的整型数和网络中的整型数进行交换时，需要相关的函数进行转换。如果将计算机中的长整型IP地址转换成网络字符顺序的整型IP地址，使用htonl函数。这些函数如下：

uint32_t htonl(uint32_t hostlong);将计算机中的32位长整型数转换成网络字符顺序的32位长整型数。(用于IP的转换)

uint16_t htons(uint16_t hostshort);将计算机中的16位整型数转换成网络字符顺序的16位整型数。。(用于port的转换)

uint32_t ntohl(uint32_t netlong);将网络中的32位常整型数转换成计算机中的32位长整型数。。(用于IP的转换)

uint16_t ntons(uint16_t netshort);将网络中的16位整型数转换成计算机中的16位整型数。。(用于port的转换)

转自:http://www.linuxidc.com/Linux/2012-01/51068.htm

  原型： int shmctl ( int shmqid, int cmd, struct shmid_ds *buf );

  返回：成功为 0 ，   失败 为-1

这个特殊的调用和semctl()调用几乎相同，因此，这里不进行详细的讨论。有效命令的值是： 

IPC_STAT ：检索一个共享段的shmid_ds结构，把它存到buf参数的地址中。 

IPC_SET ：对一个共享段来说，从buf 参数中取值设置shmid_ds结构的ipc_perm域的值。 

IPC_RMID ：把一个段标记为删除 

 IPC_RMID 命令实际上不从内核删除一个段，而是仅仅把这个段标记为删除，实际的删除发生在最后一个进程离开这个共享段时。

当一个进程不再需要共享内存段时，它将调用shmdt()系统调用卸载，即本进程不再使用这个段，但是，这并不是从内核真正地删除这个段，而是把相关shmid_ds结构的 shm_nattch域的值减1。真正把内核中的共享内存删除还得用shmctl。

mmap系统调用并不是完全为了用于共享内存而设计的。它本身提供了不同于一般对普通文件的访问方式，进程可以像读写内存一样对普通文件的操作。而Posix或系统V的共享内存IPC则纯粹用于共享目的，当然mmap()实现共享内存也是其主要应用之一。
          mmap系统调用使得进程之间通过映射同一个普通文件实现共享内存。普通文件被映射到进程地址空间后，进程可以像访问普通内存一样对文件进行访问，不必再调用read()，write（）等操作。mmap并不分配空间, 只是将文件映射到调用进程的地址空间里(因为并不分配空间所以所映射的文件必须已经具有大小，空文件会产生错误), 然后你就可以用memcpy等操作写文件, 而不用write()了.写完后用msync()同步一下, 你所写的内容就保存到文件里了. 不过这种方式没办法增加文件的长度, 因为要映射的长度在调用mmap()的时候就决定了.

信号本质

信号是在软件层次上对中断机制的一种模拟，在原理上，一个进程收到一个信号与处理器收到一个中断请求可以说是一样的。信号是异步的，一个进程不必通过任何操作来等待信号的到达，事实上，进程也不知道信号到底什么时候到达。

信号是进程间通信机制中唯一的异步通信机制，可以看作是异步通知，通知接收信号的进程有哪些事情发生了。信号机制经过POSIX实时扩展后，功能更加强大，除了基本通知功能外，还可以传递附加信息。

信号来源

信号事件的发生有两个来源：硬件来源(比如我们按下了键盘或者其它硬件故障)；软件来源，最常用发送信号的系统函数是kill, raise, alarm和setitimer以及sigqueue函数，软件来源还包括一些非法运算等操作。

二、信号的种类

可以从两个不同的分类角度对信号进行分类：（1）可靠性方面：可靠信号与不可靠信号；（2）与时间的关系上：实时信号与非实时信号。在《Linux环境进程间通信（一）：管道及有名管道》的附1中列出了系统所支持的所有信号。

1、可靠信号与不可靠信号

"不可靠信号"

Linux信号机制基本上是从Unix系统中继承过来的。早期Unix系统中的信号机制比较简单和原始，后来在实践中暴露出一些问题，因此，把那些建立在早期机制上的信号叫做"不可靠信号"，信号值小于SIGRTMIN(Red hat 7.2中，SIGRTMIN=32，SIGRTMAX=63)的信号都是不可靠信号。这就是"不可靠信号"的来源。它的主要问题是：

• 进程每次处理信号后，就将对信号的响应设置为默认动作。在某些情况下，将导致对信号的错误处理；因此，用户如果不希望这样的操作，那么就要在信号处理函数结尾再一次调用signal()，重新安装该信号。
• 信号可能丢失，后面将对此详细阐述。
  因此，早期unix下的不可靠信号主要指的是进程可能对信号做出错误的反应以及信号可能丢失。

Linux支持不可靠信号，但是对不可靠信号机制做了改进：在调用完信号处理函数后，不必重新调用该信号的安装函数（信号安装函数是在可靠机制上的实现）。因此，Linux下的不可靠信号问题主要指的是信号可能丢失。

"可靠信号"

随着时间的发展，实践证明了有必要对信号的原始机制加以改进和扩充。所以，后来出现的各种Unix版本分别在这方面进行了研究，力图实现"可靠信号"。由于原来定义的信号已有许多应用，不好再做改动，最终只好又新增加了一些信号，并在一开始就把它们定义为可靠信号，这些信号支持排队，不会丢失。同时，信号的发送和安装也出现了新版本：信号发送函数sigqueue()及信号安装函数sigaction()。POSIX.4对可靠信号机制做了标准化。但是，POSIX只对可靠信号机制应具有的功能以及信号机制的对外接口做了标准化，对信号机制的实现没有作具体的规定。

信号值位于SIGRTMIN和SIGRTMAX之间的信号都是可靠信号，可靠信号克服了信号可能丢失的问题。Linux在支持新版本的信号安装函数sigation（）以及信号发送函数sigqueue()的同时，仍然支持早期的signal（）信号安装函数，支持信号发送函数kill()。

注：不要有这样的误解：由sigqueue()发送、sigaction安装的信号就是可靠的。事实上，可靠信号是指后来添加的新信号（信号值位于SIGRTMIN及SIGRTMAX之间）；不可靠信号是信号值小于SIGRTMIN的信号。信号的可靠与不可靠只与信号值有关，与信号的发送及安装函数无关。目前linux中的signal()是通过sigation()函数实现的，因此，即使通过signal（）安装的信号，在信号处理函数的结尾也不必再调用一次信号安装函数。同时，由signal()安装的实时信号支持排队，同样不会丢失。

对于目前linux的两个信号安装函数:signal()及sigaction()来说，它们都不能把SIGRTMIN以前的信号变成可靠信号（都不支持排队，仍有可能丢失，仍然是不可靠信号），而且对SIGRTMIN以后的信号都支持排队。这两个函数的最大区别在于，经过sigaction安装的信号都能传递信息给信号处理函数（对所有信号这一点都成立），而经过signal安装的信号却不能向信号处理函数传递信息。对于信号发送函数来说也是一样的。

2、实时信号与非实时信号

早期Unix系统只定义了32种信号，Ret hat7.2支持64种信号，编号0-63(SIGRTMIN=31，SIGRTMAX=63)，将来可能进一步增加，这需要得到内核的支持。前32种信号已经有了预定义值，每个信号有了确定的用途及含义，并且每种信号都有各自的缺省动作。如按键盘的CTRL ^C时，会产生SIGINT信号，对该信号的默认反应就是进程终止。后32个信号表示实时信号，等同于前面阐述的可靠信号。这保证了发送的多个实时信号都被接收。实时信号是POSIX标准的一部分，可用于应用进程。

非实时信号都不支持排队，都是不可靠信号；实时信号都支持排队，都是可靠信号。

动态链接库*.so的编译与使用- -


动态库*.so在linux下用c和c++编程时经常会碰到，最近在网站找了几篇文章介绍动态库的编译和链接，总算搞懂了这个之前一直不太了解得东东，这里做个笔记，也为其它正为动态库链接库而苦恼的兄弟们提供一点帮助。
1、动态库的编译

下面通过一个例子来介绍如何生成一个动态库。这里有一个头文件：so_test.h，三个.c文件：test_a.c、test_b.c、test_c.c，我们将这几个文件编译成一个动态库：libtest.so。

so_test.h：

#include 
#include 

void test_a();
void test_b();
void test_c();


test_a.c：

#include "so_test.h"
void test_a()
{
printf("this is in test_a...\n");
}

test_b.c：
#include "so_test.h"
void test_b()
{
printf("this is in test_b...\n");
}

test_a.c：

#include "so_test.h"
void test_c()
{
printf("this is in test_c...\n");
}

将这几个文件编译成一个动态库：libtest.so
$ gcc test_a.c test_b.c test_c.c -fPIC -shared -o libtest.so

2、动态库的链接

在1、中，我们已经成功生成了一个自己的动态链接库libtest.so，下面我们通过一个程序来调用这个库里的函数。程序的源文件为：test.c。

test.c：

#include "so_test.h"
int main()
{
test_a();
test_b();
test_c();
return 0;

}

l 将test.c与动态库libtest.so链接生成执行文件test：

$ gcc test.c -L. -ltest -o test

l 测试是否动态连接，如果列出libtest.so，那么应该是连接正常了

$ ldd test

l 执行test，可以看到它是如何调用动态库中的函数的。
3、编译参数解析
最主要的是GCC命令行的一个选项:
-shared 该选项指定生成动态连接库（让连接器生成T类型的导出符号表，有时候也生成弱连接W类型的导出符号），不用该标志外部程序无法连接。相当于一个可执行文件

l -fPIC：表示编译为位置独立的代码，不用此选项的话编译后的代码是位置相关的所以动态载入时是通过代码拷贝的方式来满足不同进程的需要，而不能达到真正代码段共享的目的。

l -L.：表示要连接的库在当前目录中

l -ltest：编译器查找动态连接库时有隐含的命名规则，即在给出的名字前面加上lib，后面加上.so来确定库的名称

l LD_LIBRARY_PATH：这个环境变量指示动态连接器可以装载动态库的路径。

l 当然如果有root权限的话，可以修改/etc/ld.so.conf文件，然后调用 /sbin/ldconfig来达到同样的目的，不过如果没有root权限，那么只能采用输出LD_LIBRARY_PATH的方法了。
4、注意

调用动态库的时候有几个问题会经常碰到，有时，明明已经将库的头文件所在目录 通过 “-I” include进来了，库所在文件通过 “-L”参数引导，并指定了“-l”的库名，但通过ldd命令察看时，就是死活找不到你指定链接的so文件，这时你要作的就是通过修改 LD_LIBRARY_PATH或者/etc/ld.so.conf文件来指定动态库的目录。通常这样做就可以解决库无法链接的问题了。

链接要加上ncurses库, cc -l ncurses xxxx.c

如 man 里说的：

引用

brk()  and  sbrk() change the location of the program break, which defines the end of the process's data segment (i.e., the program break is the first location after the end of the uninitialized data segment).  

首先说明一点，一个程序一旦编译好后，text segment ，data segment 和 bss segment 是确定下来的，这也可以通过 objdump 观察到。下面通过一个程序来测试这个 program break 是不是在 bss segment 结束那里：

引用

[beyes@localhost C]$ ./sbrk 
end of bss section:0x8049938
pmem:0x82ec008
1-gap between heap and bss:2762448
pmem:0x82ec008
2-gap between heap and bss:2762448
[beyes@localhost C]$ ./sbrk 
end of bss section:0x8049938
pmem:0x8dbc008
1-gap between heap and bss:14100176
pmem:0x8dbc008
2-gap between heap and bss:14100176

引用

[beyes@localhost C]$ ./sbrk 
pmem:0x80c9008
heap size on each load: 135160
[beyes@localhost C]$ ./sbrk 
pmem:0x9682008
heap size on each load: 135160
[beyes@localhost C]$ ./sbrk 
pmem:0x9a7d008
heap size on each load: 135160
[beyes@localhost C]$ ./sbrk 
pmem:0x8d92008
heap size on each load: 135160
[beyes@localhost C]$ vi sbrk.c

引用

#sysctl -w kernel/randomize_va_space=0

引用

[beyes@localhost C]$ ./sbrk 
pmem:0x804a008
heap size on each load: 135160
[beyes@localhost C]$ ./sbrk 
pmem:0x804a008
heap size on each load: 135160
[beyes@localhost C]$ ./sbrk 
pmem:0x804a008
heap size on each load: 135160

引用

[beyes@localhost C]$ ./sbrk 
pmem:0x804a008
1
2
3
4
5

... ...
61
62
63
64

而 brk() 这个函数的参数是一个地址，假如你已经知道了堆的起始地址，还有堆的大小，那么你就可以据此修改 brk() 中的地址参数已达到调整堆的目的。

实际上，在应用程序中，基本不直接使用这两个函数，取而代之的是 malloc() 一类函数，这一类库函数的执行效率会更高。 还需要注意一点，当使用 malloc() 分配过大的空间，比如超出 0x20ff8 这个常数(在我的系统(Fedora15)上是这样，别的系统可能会有变)时，malloc 不再从堆中分配空间，而是使用 mmap() 这个系统调用从映射区寻找可用的内存空间。


brk/sbrk我觉得：一个程序可寻址的逻辑地址范围是3G（本来是4G，有1G是内核空间不能用），但是这只是逻辑地址，并不可能全部给你用，所以就把预定约定可以给你用的那部分空间(code\data\bss\heap\stack)映射成了物理地址。但是预先约定的总有不够用的时候，此时可以通过brk/sbrk来增加逻辑地址到物理地址映射的范围，即扩大该程序堆空间的大小。

平台如下：

CentOS 5.2 Linux kernel 2.6.18-92.e15

CPU: Intel(R) Pentium(R) 4 CPU 2.40GHz

Disk: 7200 rpm

测试的想法是: 对于writev（）， 如果有10 个buffer， 并且buffer的大小是1kb,  那么我就先依次调用write() 10 次， 每次写1KB 到同一个文件， 记录下时间， 然后记录下用writev（）的时间。 最后， 以write（）为baseline, 计算writev（）所占的%， 如果%越小， 证明writev() 的性能就越好。

做了两组测试，

第一组， 固定buffer 的个数（10， 100， 1000）， 依次增加buffer的大小， 从1KB -- 1024KB， 数据如下， （基准线为相应write（）的数据）

例如， 10 个buffer， 每个buffer size 是1KB。 write() 耗时0.092 ms, writev() 耗时0.098 ms, 图中的数据即为 1.067 (write_v10, 1KB)

图一

第二组， 固定buffer大小（1KB， 2KB， 8KB）， 依次增加buffer的数目， 从 200 -- 8000, 数据如下 （基准线为相应write（）的数据）

图二

第一组数据显示：1.  随着buffer的增大 （ > 64KB）， writev（）的性能开始跟write（）持平； 2. 如果buffer的个数过小 ， writev（）的性能是低于write（）的。 从图一可以看到，  在buffer size 小于1024KB 时， writev（） 使用10 个buffer的性能要低于100 和1000。

第二组数据显示： 1. 当保持buffer size一定情况下， 增加buffer的个数 （< 2000）， writev（） 的性能稳定在70%左右; 2. 增加buffer size, 将会降低writev()的性能。 当buffer为8KB 时， writev（） 所用时间基本上都为相应write（）时间的80%， 性能的提高明显不如1KB 和 2KB。3. 当buffer的个数超过2000， 并且buffer size 大于2KB， writev（）性能将远不如write（）。

结论：

writev() 应使用在small write intensive 的workload中， buffer size 应控制在 2KB 以下， 同时buffer的数目不要超过IOV_MAX, 否则 writev() 并不会带来性能的提高。 

现在， 所要研究的问题是对于不同的workload， 如何快速的确定writev（）中buffer的个数和大小， 从而达到较好performance。

Saturday, May 09, 2009  8:50:48 PM

一般来说，程序进行输入操作有两步：
1．等待有数据可以读
2．将数据从系统内核中拷贝到程序的数据区。

对于sock编程来说:

         第一步:   一般来说是等待数据从网络上传到本地。当数据包到达的时候，数据将会从网络层拷贝到内核的缓存中；

         第二步:   是从内核中把数据拷贝到程序的数据区中。

阻塞I/O模式                            //进程处于阻塞模式时，让出CPU，进入休眠状态
        阻塞 I/O 模式是最普遍使用的 I/O 模式。是Linux系统下缺省的IO模式。

       大部分程序使用的都是阻塞模式的 I/O 。

       一个套接字建立后所处于的模式就是阻塞 I/O 模式。（因为Linux系统默认的IO模式是阻塞模式）

对于一个 UDP 套接字来说，数据就绪的标志比较简单：
（1）已经收到了一整个数据报
（2）没有收到。
而 TCP 这个概念就比较复杂，需要附加一些其他的变量。

       一个进程调用 recvfrom  ，然后系统调用并不返回知道有数据报到达本地系统，然后系统将数据拷贝到进程的缓存中。 （如果系统调用收到一个中断信号，则它的调用会被中断）

   我们称这个进程在调用recvfrom一直到从recvfrom返回这段时间是阻塞的。当recvfrom正常返回时，我们的进程继续它的操作。

非阻塞模式I/O                           //非阻塞模式的使用并不普遍，因为非阻塞模式会浪费大量的CPU资源。
       当我们将一个套接字设置为非阻塞模式，我们相当于告诉了系统内核： “当我请求的I/O 操作不能够马上完成，你想让我的进程进行休眠等待的时候，不要这么做，请马上返回一个错误给我。”
      我们开始对 recvfrom 的三次调用，因为系统还没有接收到网络数据，所以内核马上返回一个 EWOULDBLOCK的错误。

      第四次我们调用 recvfrom 函数，一个数据报已经到达了，内核将它拷贝到我们的应用程序的缓冲区中，然后 recvfrom 正常返回，我们就可以对接收到的数据进行处理了。
      当一个应用程序使用了非阻塞模式的套接字，它需要使用一个循环来不听的测试是否一个文件描述符有数据可读(称做 polling(轮询))。应用程序不停的 polling 内核来检查是否 I/O操作已经就绪。这将是一个极浪费 CPU资源的操作。这种模式使用中不是很普遍。

 

例如:

         对管道的操作，最好使用非阻塞方式！

 

 

  ---------------------------------------------------------------------------------

 

I/O多路复用                             //针对批量IP操作时，使用I/O多路复用，非常有好。

       在使用 I/O 多路技术的时候，我们调用 select()函数和 poll()函数或epoll函数(2.6内核开始支持)，在调用它们的时候阻塞，而不是我们来调用 recvfrom（或recv）的时候阻塞。
       当我们调用 select函数阻塞的时候，select 函数等待数据报套接字进入读就绪状态。当select函数返回的时候， 也就是套接字可以读取数据的时候。 这时候我们就可以调用 recvfrom函数来将数据拷贝到我们的程序缓冲区中。
        对于单个I/O操作，和阻塞模式相比较，select()和poll()或epoll并没有什么高级的地方。

        而且，在阻塞模式下只需要调用一个函数：

                             读取或发送函数。

                   在使用了多路复用技术后，我们需要调用两个函数了：

                             先调用 select()函数或poll()函数，然后才能进行真正的读写。

       多路复用的高级之处在于::

              它能同时等待多个文件描述符，而这些文件描述符（套接字描述符）其中的任意一个进入读就绪状态，select()函数就可以返回。

 

IO 多路技术一般在下面这些情况中被使用：

1、当一个客户端需要同时处理多个文件描述符的输入输出操作的时候（一般来说是标准的输入输出和网络套接字)，I/O 多路复用技术将会有机会得到使用。
2、当程序需要同时进行多个套接字的操作的时候。
3、如果一个 TCP 服务器程序同时处理正在侦听网络连接的套接字和已经连接好的套接字。
4、如果一个服务器程序同时使用 TCP 和 UDP 协议。
5、如果一个服务器同时使用多种服务并且每种服务可能使用不同的协议（比如 inetd就是这样的）。

 

 

 

异步IO模式有::

       1、信号驱动I/O模式

       2、异步I/O模式

信号驱动I/O模式                                                   //自己没有用过。

       我们可以使用信号，让内核在文件描述符就绪的时候使用 SIGIO 信号来通知我们。我们将这种模式称为信号驱动 I/O 模式。

为了在一个套接字上使用信号驱动 I/O 操作，下面这三步是所必须的。

（1）一个和 SIGIO信号的处理函数必须设定。
（2）套接字的拥有者必须被设定。一般来说是使用 fcntl 函数的 F_SETOWN 参数来
进行设定拥有者。
（3）套接字必须被允许使用异步 I/O。一般是通过调用 fcntl 函数的 F_SETFL 命令，O_ASYNC为参数来实现。

       虽然设定套接字为异步 I/O 非常简单，但是使用起来困难的部分是怎样在程序中断定产生 SIGIO信号发送给套接字属主的时候，程序处在什么状态。

1．UDP 套接字的 SIGIO 信号                    (比较简单)
在 UDP 协议上使用异步 I/O 非常简单．这个信号将会在这个时候产生：

1、套接字收到了一个数据报的数据包。
2、套接字发生了异步错误。
        当我们在使用 UDP 套接字异步 I/O 的时候，我们使用 recvfrom()函数来读取数据报数据或是异步 I/O 错误信息。
2．TCP 套接字的 SIGIO 信号                   (不会使用)
          不幸的是，异步 I/O 几乎对 TCP 套接字而言没有什么作用。因为对于一个 TCP 套接字来说，SIGIO 信号发生的几率太高了，所以 SIGIO 信号并不能告诉我们究竟发生了什么事情。

在 TCP 连接中， SIGIO 信号将会在这个时候产生：
l  在一个监听某个端口的套接字上成功的建立了一个新连接。
l  一个断线的请求被成功的初始化。
l  一个断线的请求成功的结束。
l  套接字的某一个通道（发送通道或是接收通道）被关闭。
l  套接字接收到新数据。
l  套接字将数据发送出去。

l  发生了一个异步 I/O 的错误。

一个对信号驱动 I/O 比较实用的方面是 NTP（网络时间协议 Network Time Protocol）服务器，它使用 UDP。这个服务器的主循环用来接收从客户端发送过来的数据报数据包，然后再发送请求。对于这个服务器来说，记录下收到每一个数据包的具体时间是很重要的。

因为那将是返回给客户端的值，客户端要使用这个数据来计算数据报在网络上来回所花费的时间。图 6-8 表示了怎样建立这样的一个 UDP 服务器。

 

 

异步I/O模式             //比如写操作，只需用写，不一定写入磁盘(这就是异步I/O)的好处。异步IO的好处效率高。
      当我们运行在异步 I/O 模式下时，我们如果想进行 I/O 操作，只需要告诉内核我们要进行 I/O 操作，然后内核会马上返回。具体的 I/O 和数据的拷贝全部由内核来完成，我们的程序可以继续向下执行。当内核完成所有的 I/O 操作和数据拷贝后，内核将通知我们的程序。
异步 I/O 和  信号驱动I/O的区别是：
        1、信号驱动 I/O 模式下，内核在操作可以被操作的时候通知给我们的应用程序发送SIGIO 消息。

        2、异步 I/O 模式下，内核在所有的操作都已经被内核操作结束之后才会通知我们的应用程序。

转自:http://blog.163.com/xychenbaihu@yeah/blog/static/13222965520112163171778/

孤儿进程组： 一个进程组中的所有进程的父进程要么是该进程组的一个进程，要么不是该进程组所在的会话中的进程。 一个进程组不是孤儿进程组的条件是，该组中有一个进程其父进程在属于同一个会话的另一个组中。

GNU解释了为什么会提出孤儿进程组的概念：
       When a controlling process terminates, its terminal becomes free and a new session can be established on it. (In fact, another user could log in on the terminal.) This could cause a problem if any processes from the old session are still trying to use that terminal.
To prevent problems, process groups that continue running even after the session leader has terminated are marked as orphaned process groups.
       When a process group becomes an orphan, its processes are sent a SIGHUP signal. Ordinarily, this causes the processes to terminate. However, if a program ignores this signal or establishes a handler for it, it can continue running as in the orphan process group even after its controlling process terminates; but it still cannot access the terminal any more.

当一个终端控制进程（即会话首进程）终止后，那么这个终端可以用来建立一个新的会话。这可能会产生一个问题，原来旧的会话（一个或者多个进程组的集合）中的任一进程可再次访问这个的终端。为了防止这类问题的产生，于是就有了孤儿进程组的概念。当一个进程组成为孤儿进程组时，posix.1要求向孤儿进程组中处于停止状态的进程发送SIGHUP（挂起）信号，系统对于这种信号的默认处理是终止进程，然而如果无视这个信号或者另行处理的话那么这个挂起进程仍可以继续执行。

以下摘自网络：

       终端的问题涉及几个概念，那就是进程组，会话，作业，下面会分别进行介绍。会话包含了一系列的进程，这些进程按照不同的执行内容会组织成若干进程组，一个会话内的所有进程都必须是该会话首长进程的后代，这样就保证了这些进程都是由该会话首长进程直接或者间接开启的，只有这样的才能保证这些进程确实是在会话首长进程耳目视线之内的，同时，孤儿进程组不再受到会话首长进程的控制。
作业：
只有一个终端，但是有很多事情要同时做，或者起码分时做，不能先做完一件事再做另一件，怎么办？毕竟启动一个进程后该进程就会独占终端啊，毕竟shell会将它设置为前台进程组进程啊。这就是作业的功能，只需要在一个命令后加一个&符号就可以了，比如我要执行x，那么就敲入：
x &
shell的结果是：
[1] 1234
此处1234是进程的pid，而1则是作业的id，这样这个x就不占用终端了，shell可以启动其它的进程或者作业了，比如又启动了作业2：
[2] 4321
       此时想起作业1需要使用一下终端来输入一些信息了，那么就使用：fg %1将作业1置于前台(作业1中目前只有一个进程)，置于前台的作业如何重新放到后台呢？只需要用SIGSTOP信号停止前台使用终端的进程即可，然后该进程就放开终端的占用了
进程组：一个作业就是一个进程组，单独的进程可以独占一个进程组也可以加入同一会话的别的进程组，必须要满足的条件是，同一进程组的所有进程都要是一个会话的后代。所谓的进程组是为了组织作业或者组织同一类任务的。
控制终端：
       一个会话的建立者有权力申请一个控制终端，在该控制终端中可以接受标准输入，可以发送shell理解的控制快捷键，可以创建作业并且使用会话头进程提供的作业控制功能。控制终端只能由会话头进程创建，并且控制终端是独占的，只要有一个进程将一个终端当成了控制终端，别的进程不管它是谁都不能这么做了，tty_open中的最后有下面几行代码
if (!noctty &&
    current->signal->leader &&
    !current->signal->tty &&
    tty->session == 0) {
    task_lock(current);
    current->signal->tty = tty;
    task_unlock(current);
    current->signal->tty_old_pgrp = 0;
    tty->session = current->signal->session;  //设置session
    tty->pgrp = process_group(current);
}
可见别的进程是无权申请控制终端的。
     这个控制终端平时给谁用呢？最不容被怀疑的会话首长申请了终端，因为如果连他都值得怀疑的话，后面的属于他的孩子进程们都值得怀疑了，首长申请的终端就是给这些孩子们用的，首长将这些孩子们分成了若干的进程组，指定一个组为前台进程组，只有这个前台进程组的进程才能使用控制终端。bash一般会作为会话首长存在，bash将为一个执行的命令都创建一个进程组，它在接受一个命令准备执行的时候会将该进程设置为前台进程组，它在接受了命令行后加&的命令时，会创建一个作业，并且将它设定为后台进程组，那么此时前台是谁呢，是bash自己哦。后台进程不能使用终端，如果使用&执行了内部带有诸如getchar之类函数的进程，那么其将会收到SIGTTIN信号，不过可以使用fg命令将这类进程提到前台。
控制进程：
       很显然，首先控制进程是一个会话的首长进程，另外即使是会话首长也只能通过终端来控制别的进程，所谓的控制就是发送信号而不是操作内存之类的，这也是进程间通信的一种方式。因此所谓的控制进程就是申请到控制终端的进程。
孤儿进程组：
       有孤儿进程，对应的也有孤儿进程组的概念。为何引入这个概念以及这个概念的引入需要OS的实现者作些什么呢？先看两个前提，首先，posix用一个session的概念来描述一次用户的登录以及该用户在此次登录后的操作，然后用作业的概念描述不同操作的内容，最后才用进程的概念描述不同操作中某一个具体的工作；其次，unix最初将所有的进程组织成了树的形式，这样就便于追踪每个进程也便于管理(想想看，人类政治社会也是一个类似树形结构：君主专制，两院制等)。有了上述两个前提事情就很明白了，一切都是为了便于管理，一切都是为了登录用户的安全，即此次登录用户的作业是不能被下个登录用户所控制的，即使它们的用户名一致也是不行的，因此所谓的孤儿进程组简单点说就是脱离了创造它的session控制的，离开其session眼线的进程组，unix中怎样控制进程，怎样证明是否在自己的眼线内，那就是树形结构了，只要处于以自己为根的子树的进程就是自己眼线内的进程，这个进程就是受到保护的，有权操作的，而在别的树枝上的进程原则上是触动不得的(又想说说windows的远程线程创建了，可是说的话还要接着说其复杂的令牌机制，否则windows粉丝不服气，所以不说了罢)，unix中建立进程使用fork，自然地这么一“叉子”就形成了自己的一个树枝，当然在自己眼线了，一般对于登录用户而言一个会话起始于一次login之后的shell，只要该用户不logout，在该终端的shell上执行的所有的非守护进程都是该shell的后代进程，因此它们组成一个会话，全部在shell的眼线中，一个会话终止于会话首长的death。现在考虑一下终端上的shell退出后的情景，按照规定，该终端上所有的进程都过继给了别的进程，大多数情况是init进程，然后紧接着另外一个用户登录了这个终端或者知道前一个登录用户密钥的另一个有不好念头的人登录了该终端，当然为其启动的shell创建了一个新的session，由于之前登录的用户已退出，现在登录的用户由于之前用户的进程组都成了孤儿进程组，所以它再有恶意也不能控制它们了，那些孤儿进程组中的成员要么继续安全的运行，要么被shell退出时发出的SIGHUP信号杀死。
       POSIX的规定是铁的纪律，而unix或者linux的不管是内核还是shell的实现则是一种遵守纪律的方式，铁的纪律要求作业控制要以session为基本，就是说不能操作别的session内的进程组，所以类似fg和bg等命令就不能操作孤儿进程，因此如果由于后台进程组由于读写终端被SIGSTOP信号停了，而后它又成了孤儿进程组的成员，那怎么办？别的session的作业控制命令又不能操作它，即使ps -xj找到了它然后手工发送了SIGCONT，那么它还是没法使用终端，这是POSIX的另一个纪律要求的，只有唯一和终端关联的session中的前台进程组的进程可以使用终端，因此只要有一个shell退出了，最好的办法就是将其session内的所有的进程都干掉，因此SIGHUP的原意就是如此，但是完全可以忽略这个信号或者自己定义对该信号的反应。POSIX的基本限制就是session的ID是不能设置的，因为它是受保护的基本单位，但是进程组的ID是可以设置的，毕竟它只是区分了不能的作业，最后进程的PID也是不能设置的，因为它是进程的内秉属性，形成树形进程结构的关键属性。
     POSIX对孤儿进程组的定义：组中没有一个进程的父进程和自己属于同一个会话但是不同进程组的。

转自 http://xingyunbaijunwei.blog.163.com/blog/static/765380672011112633634628/

关于分离线程的一种用法（转）

讲到分离线程，先得从僵尸进程讲起（抱歉，确实不知道线程是否有僵尸一说）。

关于僵尸进程：一般情况下进程终止的时候，和它相关的系统资源也并不是主动释放的，而是进入一种通常称为“僵尸”(zombie)的状态。它所占有 的资源一直被系统保留，直到它的父进程（如果它直接的父进程先于它去世，那么它将被init进程所收养，这个时候init就是它的父进程）显式地调用 wait系列函数为其“收尸”。为了让父进程尽快知道它去世的消息，它会在它死去的时候通过向父进程发送SIGCHLD信号的方式向其“报丧”。

所以一旦父进程长期运行，而又没有显示wait或者waitpid，同时也没处理SIGCHLD信号，这个时候init进程，就没办法来替子进程来收尸。这个时候，子进程就真的成了”僵尸“了。

同理：

如果一个线程调用了这个函数，那么当这个线程终止的时候，和它相关的系统资源将被自动释放，系统不用也不能用pthread_join()等待其退 出。有的时候分离线程更好些，因为它潜在地减少了一个线程回收的同步点，并且pthread_join()这个API确实也是相当地难用。

为了让主线程省去去子线程收尸的过程，可以使用

int pthread_detach(pthread_t thread);

来让子线程处于分离状态，就不需要父线程再pthread_join了。

我们来看一种分离线程的用法。上次别人问道一种情况，我发现必须要分离子线程：

我 们看到，在这里task1这个线程函数居然会多次调用其父线程里的函数，显然usr函数里，我们无法等待task1结束，反而task1会多次调用 usr，一旦我们在usr里pthread_join，则在子线程退出前，有多个usr函数会等待，很浪费资源。所以，此处，将task1设置为分离线程 是一种很好的做法。

下面是实例代码：