协程并不是什么新概念，可以理解为是拥有了控制权的用户态线程，用户可以自行选择切换用户上下文(user context)的时机，不需要操作系统额外调度(Steps in Context Switching)。
光这一点就足够牛逼了，现在Linux采用的是NPTL线程模型,线程和进程在内核里边都是同样的PCB块(task_struct)，看上去还是比较重量级的。网上找来一个有趣的测试，一次线程切换的开销大概是10Kns的量级:线程切换的开销到底有多大。具体的为什么协程上下文切换比线程要快，网上也有讨论：https://www.zhihu.com/question/308641794/answer/572499202。根据这个作者的测试结果，切换协程的开销大概只有几十纳秒(ns)。
无意间看到了上大学的时候用C++ + PThread API实现的了一个简单线程池：https://github.com/baixiangcpp/TinxHttpd/blob/master/ThreadPool.h。发现了几个问题：
首先要不是这段代码出现在我的Github上，我肯定不承认这段代码是我写的。今天花时间重新设计了一个基于C++11的线程池。
相对多进程来说，多线程的一个明显的好处就是线程间数据共享容易的多。然而这种便利是有代价的，每一个写过多线程程序的程序员，都曾为它掉过头发，它正是————线程安全。那么到底什么是线程安全呢？
举个例子，想象一下你和你的朋友合租一间公寓，公寓里只有一个卫生间，正常情况下，同一时间你们中只有一个人能使用这个卫生间。这样的分配方式就是所谓的”线程安全”。其中你和你的朋友分别代表一个线程，卫生间就是线程间共享的变量。那么如何保证同一时间只有一个人在使用这个卫生间呢，常见的做法就是给卫生间装锁(mutex)，你们使用卫生间之前都需将门先锁上(lock)。当别人在使用卫生间时，你只需要在门口静静等待，直到他把门打开(unlock)。而如果这个卫生间没锁呢？你们去卫生间的时间都是任意的，就有可能发生这样的情况:当你急匆匆打开卫生间门的时候，正看到的是你的朋友洗澡的中间状态，这是非常让人惨不忍睹的画面。这样的情况就不是线程安全的。
当然保证线程安全的方法不局限于使用锁，还有其他的方法，我们后边再提。如果这发生在程序里，运气好的话程序会直接crash掉，否则就是一颗定时炸弹，指不定什么时候炸那么一下，让你不得安宁。
最近看《Linux高性能服务端编程》一书，书上对条件变量的封装比较有意思:
作者通过这样奇怪的封装，将mutex隐藏到在cond类里边。但是，这样封装的条件变量是不能正常使用的。
原问题的地址:listen(2)系统调用的backlog参数无效？。几个回答的争议也比较大。
关于这个参数man page是这么描述的：
The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.
要么是手册错了，要么就是提问者的测试的方式有问题。很可惜提问者已经把Github上测试的代码删除了，当我看到这个问题点进去的时候已经404了，无从分析了。于是我在我的服务器上展开了一次测试，我的系统版本是”4.16.3-301.fc28.x86_64”。另外本次实验listen(2)是用于TCP的，未测试作用于其他域的情况。
Seafile文件系统的设计是模仿Git的。要看懂本篇博客，你至少需要掌握Git的基本操作。如果没有使用过Git，最好还是先学习一下，磨刀不误砍柴工。
最好还能知道一些Git的内部原理，网上有一本开源的图书可以参考：https://git-scm.com/book/en/v2。当然不是要掌握全部Git的内部原理，但至少要知道repository、branch、commit等概念。