UNP 卷1 多种客户/服务器设计方式 总结

快一个月没有更新博客了，主要是因为这一个月一直在复习和深入数据结构《数据结构与算法分析》和刷了一遍《剑指offer》。个人习惯是，博客记录些总结性的内容。太基础，太浅显易懂的内容留在印象笔记里。

这边博客主要讲述多种客户/服务器设计方式的一些我认为比较重要的知识点，还有第一次正式使用CLion打项目型代码遇到的问题。

配置出现问题，包括CLion里的

没有搭建unp环境的，看这里搭建环境。
搭建环境主要是为了得到
（1）静态库libunp.a：放到/usr/lib/
（2）unp.h config.h：放到/usr/include/
config.h是生成系统的配置，unp.h是每个文件都要包含的，libunp.a是unp.h里面声明的函数的具体实现。
简单说就是，虽然每个文件包含unp.h，但是unp.h并没有实现一些函数，具体的实现都在静态库libunp.a中，所以每次编译的时候，都要加上-lunp，都要g++ main.cpp -o main -lunp。
-lunp：-l就是链接静态库，unp就是代表libunp.a这个文件。

想要知道 .a 文件：ar -t libunp.a 。就可以知道里面由哪些文件编译而成。具体的代码只能回去make的地方 /unp/lib/查看源码。

问题1：为什么我使用g++ main.cpp -o main -lunp会提示许多函数未定义引用，难道是我没有成功使用-lunp？

如果没成功引入，应该会提示没有找到这个静态库，而不是函数未定义引用。
出现这个问题主要是因为libunp.a是c语言的编译成的静态库，c++静态库和c语言静态库格式的标准是不一样的，但是两者通过少许修改可以相互调用。见下图。

#ifdef __cplusplus
extern "C" {               // 告诉编译器下列代码要以C链接约定的模式进行链接
#endif

#include "unp.h"

#ifdef __cplusplus
}
#endif

问题2：涉及线程的模块使用unp.h报错？

/* Our own header for the programs that use threads.
Include this file（unpthread.h）, instead of “unp.h”. */

应该是从源码文件中取出头文件unpthread.h，放到我们的项目里，然后include;

问题3：CLion如何链接静态库？

在CMakeList.txt里加入
link_libraries(libunp.a)

问题4：涉及线程内容，引入了unpthread.h还是报未定义引用错误？

对于命令行中编译，要加上 -pthread ；
对于CLion，在CMakeList.txt文件中，看到下面这一行

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 ")

在c++11后面直接加上 -pthread

set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11 -pthread")

多种客户/服务器设计方式

最近重新码了一遍UNP 卷1，第30章，多种客户/服务器设计方式中服务器的8种模式

进程相关5种：
（1）一个客户对应由一个服务器子进程负责
（2）预生成一堆子进程，不用锁。
（3）预生成一堆子进程，用文件锁。
（4）预生成一堆子进程，用线程互斥变量
（5）预生成一堆子进程，把accept集成到父进程上，由父进程分配哪个子进程去接业务。

线程相关3种：
（1）类似进程（1），one to one负责
（2）预生成一堆子线程
（3）预生成一堆子线程，但是使用条件变量，致使accept集成到父主线程上行

上面是大体内容。

只总结有意义的知识点：

1.预生成池肯定要比收到通知才生成的效率要高。
2.对于进程与线程，无论进程预生成还是怎样，效率都没有线程各种模式高。看来fork的开销很大。
3.为什么有上锁操作？
因为一些内核中，accept不是原子操作。锁可以保护accept，使得只有一个子进程阻塞在accept上，其他进程阻塞在锁上。
4.互斥量一定要初始化，但是 不同进程之间的互斥量方式和同一进程内的是不同的。
（1）同一进程互斥量初始化：只需要一个全局的互斥量。

pthread_mutex_t mlock=PTHREAD_MUTEX_INITIALIZER

（2）不同进程之间需要把互斥量映射到一个文件（一块内存）。
5.为什么出现在父进程集成accept再分配的方案？
优点是不用上锁保护，因为在统一一个位置accept。
缺点是代码复杂。要传递描述符。