Use fiber (fiber/userspacethread) in Asynchronous Communication)

In asynchronous communication, a thread is generally used to select/poll/epoll. After receiving the signal, the message header or the entire message is decoded, and the corresponding FD is handed over to other threads for processing.

This seems to be a good method, but if you use TCP and encounter a complicated dispatching process: the size of the received message is unknown, the serialization method can only be used to decode a message and distribute the message based on its content. In most cases, the entire message can be read and decoded without interruption, but there is also a small possibility of blocking on a message (incomplete messages ).

In this case, the thread pool is often used. Once a select thread obtains a readable signal, it submits the corresponding FD to the thread pool for processing. This solves the problem, but there is another new problem: the overhead of thread switching is too large. In a high-speed LAN, if the actual execution time of each request is very short, the problem will be significant.

After thinking for a long time, I also came up with a solution: Using Fiber/userspacethread, the Chinese translation of fiber/user space thread, please read it here.

After the select thread receives the reading signal, it still performs decoding. if the message is incomplete, it switches the current execution thread to the select execution thread. In the line that says, it suspends the current fiber and switches to the select fiber. Because these fiber instances run in the user space, the speed is very fast and kernel scheduling is not required. In fact, the speed improvement is mainly not here, but in most cases there is no need to switch the thread.