The epoll package of boost adopts the so-called leader followers mode.
We know that epoll_wait cannot be called in multiple threads;
To simulate the proactor mode in Linux, Asio uses the data structure at the application layer to simulate the complete packet queue implemented by iocp in windows,
And Io request packets;
To simulate multiple iocp worker threads calling getqueuedcompletedstatus,
Since epoll_wait cannot be concurrently executed, the leader follow-up mode is adopted and a rough simulation is made.
How does one feel that proactor is intended for proactor?
Linux socket does not support these features.
There is another problem,
ASIO allows the application layer to deliver multiple Recv requests to epoll;
This is confusing. I believe that there are very few iocp service programs that repeatedly deliver requests on the same handle;
/* For example, multiple Recv requests may exist. epoll_reactor: Run processes requests in sequence.
If you have any questions, you cannot specify the buffer address to receive the request.
(Or you can specify it, but it feels strange: for example, for two Recv requests, each specified read 10 bytes, so the first
The buffer address specified in the request is Buf, BUF + 10, BUF + 10, and BUF + 20.
If the first request is not completely satisfied and only reads 5 bytes, how can this problem be solved ?)
I always feel that it is unnecessary for the server program to deliver multiple Recv requests.
However, according to the intention of the boost author, the buffer associated with each Recv request can only be independent.
*/