脚踏实地，仰望星空

上节在图片传输中，在主线程main中加入了epoll，结果和上上节的图片传输一结合，各种问题。【问题】：将套接字设置成非阻塞，然后在epoll检测到sockfd有新数据时创建线程进行处理。然后问题来了，小图片第一次传输成功，第二次传输不成功；大图片一次传输都不成功；服务端图片size第一次打印正常 ，第二次打印乱码。【解决步骤1】：于是将图片换成内容全是1和全是2的文本文件，来帮助检测。果

版本版本简述放弃理由1多进程：一个任务对应一个连接，一个连接对应一个进程。所有进程都需与特征库中所有特征计算相似度。特征库应共享，但多进程进程间共享困难。2多线程：一个任务对应一个连接，一个连接对应一个线程。文件描述符太多，需要统一管理。3多线程：ep

任务队列底层容器的选择：         现在使用的是包装stl::queue后的自定义struct。std::queue可以使用deque（双端队列）作为底层容器（queue q）;也可以使用list作为底层容器(queue > q)。         若底层容器使用list，每个节点除任务信息外，均含一个指向下个节点的next指针索引。虽然相对于以deque为底层容器的队列，更能利用分

2.22思考：作为持有读写日志文件的指针的log类以及持有任务队列的server类，他们应该做成单例模式。

1.32bit系统，4G寻址空间，按线程栈10M来算（ulimit -a 查看stack size 默认为8192KB，即8M），系统最多支持400个线程。按原先的做法，将accept的套接字的缓冲区交由epoll监听，epoll监听到有数据之后，开新线程来处理。这样做有个两个大问题：【1】即使监听到了有新数据，由于新线程开不出来，还是没法处理数据，且因为EPOLLONESHOT的原因，再也没法收到读的信号，数据会一直卡在缓冲区中。【2】图

服务器端在选出匹配度高的图片后，将多个图片发送给客户端，结果客户端除了第一个图片正常外，其余都是乱码；运气好时，能有两个是正确的。打印客户端接收数据如下136199�������l~,s8�[��:��<���zӓNjxn% �펿*% N��K��A�pGS�����[�`7�aC��������94H�&2�;��2�1��MS';f�J�6�4C��s�EHLȈLr

参考：http://blog.youkuaiyun.com/pirlck/article/details/52846550http://blog.youkuaiyun.com/zhaocj/article/details/40742191SIFT提取的特征具有旋转不变性（视角差异带来的物体内容旋转）和尺度不变性（拍摄差异带来的物体内容的模糊、清晰），但是不具备仿射不变性（无法应对视角差异带来的

【1】SIFT特征没有自己编写，使用了opencv的SIFT特征提取、匹配函数。【2】centos6.8装opencv3.0有问题，系统更换成了ubuntu14.04.4。opencv3已将sift库去掉，需要自己在git上下载编译，但是编译出来错误很多，诸多不顺，最终换成了老版本。opencv2.4.9，系统ubuntu14.04.4，很顺利。【3】opencv特征库的描述子提取出来是c

1.用readn代替read的原因为避免频繁的调用read。read调用系统调用，系统调用需要在用户态和核心态转换，需要保存上下文，频繁调用read，会使系统性能下降，in指标上升。为避免频繁调用read，我们在用户空间创建用户缓冲区，将套接字的缓冲区的内容全部读入用户缓冲区后，一次性把用户缓冲区的内容用read写入内核缓冲区。这样可以提高效率。相同的writen也是这个原因。ss

问题描述：在main中加入了捕捉【硬件错误引起的SIGBUS等信号】的代码，然后图片无法传输了。解决问题步骤描述：通过 数次的注释信号安装sigaction，发现问题是由该代码引起。用fprintf打印函数执行情况，发现卡在了loadimge，的log_DEBUG中，于是gdb打印线程栈嗯，果然死锁了，但是为什么卡的锁不一样，但所有线程都锁了呢？于是先注释掉了【开线程写

SIFT解决的问题及其思路SIFT之前更加传统的匹配图像的方法是使用颜色、灰度等全局特征来描述整张图像，进而用这些全局特征去匹配图像。这样拍摄的光照、角度等因素对图像匹配的影响巨大。解决的问题：1.图像匹配时，两张相同图像，因为拍摄远近、模糊不同，导致匹配不出来。2.图像匹配时，两张相同图像，因为拍摄角度、方向不同，导致匹配不出来。3.图像匹配时，两张相同图像，

【信号的分类】：1.SIGKILL、SIGSTOP这两个信号单独一类，这两个信号不能被捕捉、忽略和阻塞。表示杀死进程和暂停进程，它们为root提供了一种一定可以杀死或暂停进程的方法。2.SIGBUS、SIGFPE、SIGSEGV这类由硬件引起的硬件故障、段错误、除0错误等信号只会发送给引起该硬件错误的线程。3.SIGCHLD、SIGALRM、SIGUSR1等等普通信号【信号

出的问题，本机同时开两个客户端，发送数据给服务器，服务器只处理其中一个后发现：是两个客户端都用了同个端口号。导致其中一个线程都空了所有数据，另一个就没有数据可读了。简易线程池的实现：pool_init中初始化number个线程，这些线程全部调用pool_route函数，pool_route则不断的从任务队列中摘取任务执行（任务即回调函数指针和回调函数的参数）。用户需要做

上回写的日志系统，我发现在ctrl+\使服务器突然断开后，产生的日志并没有及时地写入到磁盘文件中，磁盘中的日志还是空白的，这样无法应对服务器异常崩溃地情况。于是在LOG类中，添加了writeback的方法。起先writeback中只是简单的调用fclose，然后在fopen日志文件，重定位到文件尾部。【结果】：文件是空白的。是的，fclose只是将文件在用户缓冲区的内容写入到了内核缓冲

0.服务器端模型选择大体思路是：在主线程中使用epoll承受高并发连接，在主线程中开辟工作线程用来处理就绪的描述符。嗯，这个原来有官名，叫反应者模式。事件驱动编程。另外工作线程处理的就绪的文件描述符最好是非阻塞的。

今早将原先sever的纯c代码，改写成C++类，一运行，昨天好好的，改完之后就跑不起来了。于是查啊查，查了一早上，最终定位到LOG的MUTEX这边。非常奇怪的是当我在MUTEX的构造，析构函数中加入fprintf打印输出时，serv运行正常，但当我将fprintf注释掉后，serv就卡在那儿，下不去了。百试百灵，这还能忍？！！！谁干的坏事儿？，于是我将makefile中的-O2，编

线程安全的日志系统主要利用的是c++对象生命周期来管理log，使得各个线程可以同步的在server_log文本文件中输出。LOG log定义成所有线程共享的变量，log有一把mutex，提供互斥的写server_log文件。使用MUTEX类可以很好的避免重复释放mutex，忘记释放mutex等等问题。明天得把原先的代码全改成class的。

这个图像检索服务器在服务端的工作：1.接收客户端发来的图片+2.计算图片特征向量，匹配特征库图像+3.发回topK的相似图片。上版的做法：一个eopll主线程循环检测是否有连接进来==》检测到连接，装填读任务队列==》读任务调度线程循环检测是否有读任务==》检测到读任务，分派工作线程去处理==》工作线程读完客户端发来的图片，装填计算图片片特征向量，匹配特征库图像队列===》计算队列调度