asio готовится к принятию в стандарт?
От: niXman Ниоткуда https://github.com/niXman
Дата: 22.04.15 21:16
Оценка: 6 (1)
глянул ньюсы по последней небустовой версии, и обрадовался.



просто оставлю это тут.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Отредактировано 22.04.2015 21:21 niXman . Предыдущая версия . Еще …
Отредактировано 22.04.2015 21:19 niXman . Предыдущая версия .
Re: asio готовится к принятию в стандарт?
От: fdn721  
Дата: 23.04.15 05:34
Оценка: +1 -1
Да зачем оно там нужно в таком виде???

Когда они сделают возможность закрыть сокет, и дождаться завершения всех асинхронных хэндлеров по нему без тонны костылей и/или без остановки io_service? Это же просто ужас какой-то!
Re[2]: asio готовится к принятию в стандарт?
От: ArtDenis Россия  
Дата: 23.04.15 05:37
Оценка:
Здравствуйте, fdn721, Вы писали:

F>Да зачем оно там нужно в таком виде???


F>Когда они сделают возможность закрыть сокет, и дождаться завершения всех асинхронных хэндлеров по нему без тонны костылей и/или без остановки io_service? Это же просто ужас какой-то!


А в чём проблема-то это сейчас сделать?
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[3]: asio готовится к принятию в стандарт?
От: fdn721  
Дата: 23.04.15 05:55
Оценка:
Здравствуйте, ArtDenis, Вы писали:

AD>А в чём проблема-то это сейчас сделать?


А как? Ну вот к примеру стандартная ситуация:
class MyClient
{
protected:
  tcp::socket m_socket;

public:
  bool Open()
  {
    ....
    m_socket.async_connect( m_endpoint, boost::bind( &MyClient::HandleConnect, this, _1 ) );
  }

  void Close()
  {
    m_socket.close()
  }

protected:
  void HandleConnect(  const boost::system::error_code& err )
  {
    //do somthing
  }

}

int main()
{
  ...
  MyClient *client = new MyClient();
  client->Open();
  client->Close();   //<<---- Тут ASIO запланирует вызов HandleConnect со значением error::operation_aborted.
  delete client;     //<<---- А сам вызов HandleConnect может быть уже после удаления client.
  ...
}

Как с этим бороться без кучи костылей???
Re[4]: трололо
От: о_О
Дата: 23.04.15 06:10
Оценка: +1 -1
Здравствуйте, fdn721, Вы писали:

F>Как с этим бороться без кучи костылей???


ну, ты эта, не массив сортируешь...
асинхронные вещи требуют асинхронного управления. вся asio — костыль, но твой пример хреновый аргумент против.
Re[5]: трололо
От: fdn721  
Дата: 23.04.15 06:28
Оценка: +2
Здравствуйте, о_О, Вы писали:

о_О>ну, ты эта, не массив сортируешь...

о_О>асинхронные вещи требуют асинхронного управления. вся asio — костыль, но твой пример хреновый аргумент против.

С асинхронными вещами трудно работать. Иногда нужно просто выполнить несколько несложных операций, а они навязывают тебе целую идеологию и архитектуру.

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

И вообще во всей документации и примерах по ASIO старательно умалчивают про корректное завершение работы.
У них там бесконечный цикл в main, а все данные обрабатываются прямо в классе клиента. А как только ты начинаешь взаимодействовать из клиент с остальными частями программы, опять возникает куча проблем.

Я не против того что так устроена сторонняя библиотека ASIO, но тащить непродуманное решение в стандарт я бы не стал.
Re: asio готовится к принятию в стандарт?
От: flаt  
Дата: 23.04.15 07:04
Оценка:
Здравствуйте, niXman, Вы писали:

X>Implemented changes to substantially reflect the Networking Library Proposal (N4370).

Boost.Asio была предложена ещё в 2006 году в рамках TR2.
Re[6]: трололо
От: flаt  
Дата: 23.04.15 07:19
Оценка:
Здравствуйте, fdn721, Вы писали:

F>С асинхронными вещами трудно работать. Иногда нужно просто выполнить несколько несложных операций, а они навязывают тебе целую идеологию и архитектуру.

Именно поэтому сейчас продвигают resumable functions (async/await) как помощь в решении проблем с асинхронностью.
Re[4]: asio готовится к принятию в стандарт?
От: ArtDenis Россия  
Дата: 23.04.15 07:29
Оценка: +1
Здравствуйте, fdn721, Вы писали:

F>Как с этим бороться без кучи костылей???


Мда... Тяжёлый случай. Название библиотеки не пробовал расшифровывать?
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[6]: трололо
От: ArtDenis Россия  
Дата: 23.04.15 08:13
Оценка:
Здравствуйте, fdn721, Вы писали:

F>С асинхронными вещами трудно работать.


Ну так не работай. Работай в блокирующем режиме. Библиотека позволяет.
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[5]: asio готовится к принятию в стандарт?
От: fdn721  
Дата: 23.04.15 09:10
Оценка:
Здравствуйте, ArtDenis, Вы писали:

AD>Мда... Тяжёлый случай. Название библиотеки не пробовал расшифровывать?


И что мне делать с названием библиотеки? Ну асинхронная она и что теперь сокеты не закрывать и объекты не удалять?
Re[6]: asio готовится к принятию в стандарт?
От: ArtDenis Россия  
Дата: 23.04.15 09:37
Оценка:
Здравствуйте, fdn721, Вы писали:

F>И что мне делать с названием библиотеки? Ну асинхронная она и что теперь сокеты не закрывать и объекты не удалять?


Ну так и работай в асинхронном стиле, если ты её используешь в асинхронном стиле. Ваш КО.
В чём проблема-то?
[ 🎯 Дартс-лига Уфы | 🌙 Программа для сложения астрофото ]
Re[4]: asio готовится к принятию в стандарт?
От: PM  
Дата: 23.04.15 10:43
Оценка: +1
Здравствуйте, fdn721, Вы писали:

F>А как? Ну вот к примеру стандартная ситуация:

[здесь был код]
F>Как с этим бороться без кучи костылей???

Общепринятый подход показан в примерах к Boost.asio — положиться на подсчет ссылок в shared_ptr, передавать shared_ptr вместо this в асинхронные обработчики. Тогда при завершении последнего обработчика, объект будет удален.

class MyClient : public boost::enable_shared_from_this<MyClient>
{
protected:
  tcp::socket m_socket;

public:
  bool Open()
  {
    ....
    m_socket.async_connect( m_endpoint, boost::bind( &MyClient::HandleConnect, shared_from_this(), _1 ) );
  }

  void Close()
  {
    m_socket.close()
  }

protected:
  void HandleConnect(  const boost::system::error_code& err )
  {
    //do somthing
  }

}

int main()
{
  ...
  boost::shared_ptr<MyClient> client = boost::make_shared<MyClient>();
  client->Open();
  client->Close();   //<<---- Тут ASIO запланирует вызов HandleConnect со значением error::operation_aborted.
//  delete client;     //<<---- не нужно, объект будет удален, когда на него не останется ссылок
  ...
}
Re[6]: asio готовится к принятию в стандарт?
От: smeeld  
Дата: 23.04.15 10:46
Оценка: -2
Здравствуйте, fdn721, Вы писали:

F>И что мне делать с названием библиотеки? Ну асинхронная она и что теперь сокеты не закрывать и объекты не удалять?


Нужное поведение достаточно просто внедрить своим патчем. Будет asio вести себя как нужно
отдельно взятому индивиду. На то он и опенсорс.
Re[5]: asio готовится к принятию в стандарт?
От: fdn721  
Дата: 23.04.15 12:25
Оценка: -1
Здравствуйте, PM, Вы писали:

PM>Общепринятый подход показан в примерах к Boost.asio — положиться на подсчет ссылок в shared_ptr, передавать shared_ptr вместо this в асинхронные обработчики. Тогда при завершении последнего обработчика, объект будет удален.


Да видел я все эти примеры, только они все однотипные. Вся обработка идёт внутри этого самого "MyClient". Только я не эхо сервер/клиент пишу. А как только начинаешь взаимодействовать из MyClient с остальной частью программы вылезают все те же самые проблемы с кучей асинхронных операций, которые невозможно просто взять и завершить.

ЗЫ По началу кажется что ASIO это очень мощное решение, а по факты всегда всё сводится к одному подходу. Шаг влево, шаг в право и у тебя куча проблем.
Re[6]: asio готовится к принятию в стандарт?
От: PM  
Дата: 23.04.15 12:55
Оценка: +1
Здравствуйте, fdn721, Вы писали:

F>Да видел я все эти примеры, только они все однотипные. Вся обработка идёт внутри этого самого "MyClient". Только я не эхо сервер/клиент пишу. А как только начинаешь взаимодействовать из MyClient с остальной частью программы вылезают все те же самые проблемы с кучей асинхронных операций, которые невозможно просто взять и завершить.


F>ЗЫ По началу кажется что ASIO это очень мощное решение, а по факты всегда всё сводится к одному подходу. Шаг влево, шаг в право и у тебя куча проблем.


В вашем примере кода была обычная проблема со временем жизни объекта, которая решается обычным способом

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

Может быть я ошибаюсь, и есть альтернативы Asio? Я немного работал с libuv, там тоже не все просто.
Re[7]: asio готовится к принятию в стандарт?
От: smeeld  
Дата: 23.04.15 13:11
Оценка: +2 :)
Здравствуйте, PM, Вы писали:


PM>Проблемы будут с asio, как и с какой-то другой библиотекой асинхронности, потому что асинхронность это сложно. И часто асинхронность используют еще и многопоточной среде, что только добавляет сложности.


В asio сама реализация асинхронности занимает наименьшую часть кода. И это самая простая часть кода. Всё остальное-это
врайперы, сводящие воедино кучи интерфейсов и куч ОСей.

PM>Может быть я ошибаюсь, и есть альтернативы Asio? Я немного работал с libuv, там тоже не все просто.


Если нет требоавания кроссплатформа, то писать на нативном API ОС, будет проще, чем разбираться с
фантазиями создателей asio.
Re[4]: asio готовится к принятию в стандарт?
От: flаt  
Дата: 23.04.15 17:00
Оценка:
Здравствуйте, fdn721, Вы писали:

F>А как? Ну вот к примеру стандартная ситуация:

F>Как с этим бороться без кучи костылей???
Кстати, можно использовать синхронные варианты
Re[8]: asio готовится к принятию в стандарт?
От: kaa.python Ниоткуда РСДН профессионально мёртв и завален ватой.
Дата: 23.04.15 23:56
Оценка: +2
Здравствуйте, smeeld, Вы писали:

S>Если нет требоавания кроссплатформа, то писать на нативном API ОС, будет проще, чем разбираться с

S>фантазиями создателей asio.

Только в результате получится еще одно ASIO реализующее фантазии другого автора, только более глючное, так как в отладку вложить сопоставимые ресурсы будет трудно. Не нравится ASIO – возьми другую библиотеку по вкусу, благо альтернатив очень много.
Re[6]: asio готовится к принятию в стандарт?
От: jazzer Россия Skype: enerjazzer
Дата: 24.04.15 05:24
Оценка: -1
Здравствуйте, fdn721, Вы писали:

F>Да видел я все эти примеры, только они все однотипные. Вся обработка идёт внутри этого самого "MyClient". Только я не эхо сервер/клиент пишу. А как только начинаешь взаимодействовать из MyClient с остальной частью программы вылезают все те же самые проблемы с кучей асинхронных операций, которые невозможно просто взять и завершить.


проверить в этой "куче асинхронных операций" error::operation_aborted религия не позволяет?
jazzer (Skype: enerjazzer) Ночная тема для RSDN
Автор: jazzer
Дата: 26.11.09

You will always get what you always got
  If you always do  what you always did
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.