Mastering the blocking IO model of learning notes for Python introductory development

The point of this section

• Master blocking IO Model

The duration of this section needs to be controlled 15 Within minutes

Blocking IO（blocking IO）

stay linux in , By default, all socket All are blocking, A typical read operation flow is like this ：

When the user process calls recvfrom This system call ,kernel He began IO The first stage of ： Prepare the data . about network io Come on , Many times the data hasn't arrived at the beginning （ such as , I haven't received a complete UDP package ）, This is the time kernel Just wait for enough data to come .

 On the user process side , The whole process will be blocked . When kernel Wait until the data is ready , It will take data from kernel Copy to user memory ,
then kernel Return results , The user process is released block The state of , Run it again .

therefore ,blocking IO It is characterized by IO Two stages of implementation （ Waiting for data and copying data ） All be block 了 .

 Almost all network programming that programmers first come into contact with comes from listen\(\)、send\(\)、recv\(\) Wait for the interface to start ,
Using these interfaces makes it easy to build servers / The model of the client . But most of them socket Interfaces are all blocking . Here's the picture
ps：
A blocking interface is a system call （ It's usually IO Interface ） Do not return the call result and keep the current thread blocked
Only when the system call gets the result or the timeout error returns .

actually , Unless otherwise specified , Almost all IO Interface ( Include socket Interface ) It's all blocking . This brings a big problem to network programming , As in the call recv(1024) At the same time , Threads will be blocked , in the meantime , Threads will not be able to perform any operations or respond to any network requests .

A simple solution ：

 Use multithreading on the server side （ Or multiple processes ）. Multithreading （ Or multiple processes ） The goal is to have separate threads for each connection （ Or the process ）,
In this way, the blocking of any connection will not affect other connections .

The problem with the scheme is ：

 The way to start multiple processes or threads , In response to hundreds of connection requests at the same time , No matter multithreading or multiprocessing, it will occupy system resources seriously ,
Reduce the response efficiency of the system to the outside world , And threads and processes themselves are more likely to enter the pseudo dead state .

The improved scheme ：

 Many programmers may consider using “ Thread pool ” or “ Connection pool ”.“ Thread pool ” Designed to reduce the frequency of thread creation and destruction ,
It maintains a reasonable number of threads , And let the idle thread assume the new execution task again .“ Connection pool ” Maintain the connected cache pool , Try to reuse existing connections 、
Reduce the frequency of creating and closing connections . Both of these technologies can reduce the system overhead very well , Are widely used in many large systems , Such as websphere、tomcat And various databases .

There are also problems in the improved scheme ：

“ Thread pool ” and “ Connection pool ” Technology only alleviates frequent calls to a certain extent IO The resource occupation brought by the interface . and , So-called “ pool ” There is always a ceiling ,
When the request is well over the upper limit ,“ pool ” The response of the constructed system to the outside world is not much better than when there is no pool . So use “ pool ” The scale of the response it faces... Has to be considered ,
And adjust according to the response scale “ pool ” Size .

Corresponding to the possible simultaneous tens or even tens of thousands of client requests in the above example ,“ Thread pool ” or “ Connection pool ” Maybe it can relieve some of the pressure , But it doesn't solve all the problems . All in all , Multithreading model can solve small-scale service request conveniently and efficiently , But in the face of large-scale service requests , The multithreading model also has bottlenecks , You can try to solve this problem with a non blocking interface .