boost :: asio :: async_read_some запускается в родительском потоке

Если вам нужны конкретные обработчики, вызываемые в определенных потоках, используйте разные io_service объекты. Например, acceptor может быть построен с io_service1и розетки могут быть построены с io_service2, Основной поток может затем выполнить io_service1.run()в то время как потоки в пуле потоков выполняют io_service2.run(),

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

В целом, я думаю, что концептуальный дизайн в порядке, но у меня есть несколько предложений по реализации:

• q_sock Код потребителя и производителя представляет собой смесь конструкций более высокого уровня и более низкого уровня. Использование условной переменной немного неидиоматично, и возникает вопрос, почему sem_t используется вместо boost::mutexи замки. Например, следующий код потребителя и производителя:

  // Consumer
  while(1)
  {
  sem_wait(&_sem_sock);
  v_size = q_sock.size();
  sem_post(&_sem_sock);
  
  if (v_size <= 0)
  m_cond1.timed_wait(m_lock1, boost::posix_time::milliseconds(5000));
  else
  break;
  }
  sem_wait(&_sem_sock);
  curr_sock = q_sock.front();
  q_sock.pop();
  sem_post(&_sem_sock);
  
  // Producer
  sem_wait(&_sem_sock);
  q_sock.push(sockptr);
  sem_post(&_sem_sock);
  m_cond1.notify_all();
  

  Может быть переписан без использования sem_tи быть немного более идиоматичным на основе Boost.Thread’s condition_variable документация. Рассмотрим альтернативу:

  // Consumer
  boost::unique_lock<boost::mutex> lock(m_log1);
  while (q_sock.empty())
  {
  m_cond1.wait(lock);
  }
  curr_sock = q_sock.front();
  q_sock.pop();
  lock.unlock();
  
  // Producer
  {
  boost::lock_guard<boost::mutex> lock(m_log1);
  q_sock.push(sockptr);
  }
  m_cond1.notify_all();
  

• Неясно, какой функционал session обеспечивает.

  • Это только кажется, что он служит средством выделения сокета и помещения его в очередь. Почему бы просто не выделить сокет напрямую и не сделать так, чтобы вызывающий абонент поместил его в очередь?
  • session::sockptr управляется с помощью умного указателя, но session не является. С session не управляется с помощью интеллектуального указателя, утечка памяти происходит в server::handle_acceptкак ручку session теряется в переназначении.

  Определите, какие функции session это обеспечить и разработать интерфейс вокруг этого.

  • Если он предназначен для обеспечения инкапсуляции, то функции, не являющиеся членами, такие как handle_read1, возможно, потребуется стать членом функции.
  • Если session имеет свою собственную асинхронную цепочку и предоставляет себя обработчикам, затем рассмотрите возможность использования enable_shared_from_this. Boost.Asio руководство предоставляет пример использования, как и некоторые из Примеры.

• В данный момент, async_read_some не указывает, какой сокет готов для чтения. К тому времени ReadHandler был вызван, данные были прочитаны.

  Это принципиальное различие между Proactor и Reactor. Если вам нужны операции в стиле Reactor, используйте boost::asio::null_buffers. Увидеть этот документация для более подробной информации. Тем не менее, есть последствия для каждого подхода. Таким образом, очень важно понимать эти последствия, чтобы можно было принять наилучшее решение.

• С Boost.Asio, обеспечивающим демультиплексирование событий с помощью высокоуровневых конструкций, sock_dispatch нить может показаться непрактичной. session::start функция-член может инициировать асинхронное чтение в сокете. Это незначительное изменение устранит необходимость q_sockи все конструкции синхронизации в примере кода.

• Изучите, почему должна использоваться синхронная запись. В случае эхо-клиентов, как показано в примере, часто бывает так, что асинхронные записи могут использоваться путем управления потоком самой асинхронной цепочки для устранения конфликта ресурсов. Это позволяет каждому соединению иметь свой собственный буфер, который можно использовать как для чтения, так и для записи.

• Не предварительно оптимизируйте. Асинхронное программирование сложнее отладить в результате инвертированного потока управления. Попытка предварительной оптимизации пропускной способности только усугубит проблему сложности. Как только программа заработает, выполните проверку пропускной способности. Если результаты не соответствуют требованиям, то профиль для определения узкого места. По моему опыту, большинство серверов с высокой пропускной способностью будут связаны с вводом / выводом задолго до того, как будут связаны с процессором.