Не принимается при обращении с async_accept?

Question

Я пытаюсь изучить ASIO boost, но мне трудно понять его. Я хотел бы сделать базовый макет для сервера, который должен быть масштабируемым и эффективным.

В следующем URL приведен пример, где маленький TCP сервер настроен: http://www.boost.org/doc/libs/1_42_0/doc/html/boost_asio/tutorial/tutdaytime3/src.html

То, что я не понимаю, следующая часть:

void start_accept() 
{ 
tcp_connection::pointer new_connection = 
    tcp_connection::create(acceptor_.io_service()); 

acceptor_.async_accept(new_connection->socket(), 
    boost::bind(&tcp_server::handle_accept, this, new_connection, 
     boost::asio::placeholders::error)); 
} 

void handle_accept(tcp_connection::pointer new_connection, 
    const boost::system::error_code& error) 
{ 
    if (!error) 
    { 
    new_connection->start(); 
    start_accept(); 
    } 
} 

start_accept() в конечном итоге вызывает async_accept(), который вызывает его обработчик, когда он получает данные. И обработчик вызывает start_accept() при выполнении.

Но что произойдет, если клиент попытается соединиться, когда обработчик все еще будет работать? Не правда ли, что запрос не мог быть обработан, потому что async_accept() больше не слушал?

Надеюсь, вы можете указать мне в правильном направлении, если я вижу вещи в неправильной перспективе.

Answer 1

Я думаю, вы заметили, что посты Обработчика нового async_accept операции сразу же после обработки акцепта (new_connection->start()):

void handle_accept(tcp_connection::pointer new_connection, 
    const boost::system::error_code& error) 
{ 
    if (!error) 
    { 
    new_connection->start(); // this posts connection specific asynch operations 
    start_accept();   // THIS POSTS THE ASYNC OPERATION AGAIN 
    } 
} 

Вы спрашиваете, есть ли состояние гонки там (где новый асинхронной принять не в ожидании в тот момент, когда ядро ​​получает соединение).

Нет такой расы, так как ядро ​​приостанавливает события в реализации стека TCP/IP.

---

В самом деле, посмотрите на традиционные select/poll/epoll подходы, подобным образом, вы не получаете асинхронный сигнал, когда сокет изменяет состояние. Вместо этого вы можете опросить его на свой собственный досуг.

Ядро будет иметь ограничения по времени, размеру и количеству буфера в ожидающих события событиях, поэтому, если вы не сможете обработать события в течение определенного времени, они могут исчезнуть.

До тех пор, пока код userland не имеет прямого контроля над необработанным оборудованием, там никогда не будет условия гонки, так как стек ОС должен будет абстрагировать запросы прерываний на нижнем уровне (иначе вы бы назвали эту ОС ExoKernel).