Здравствуйте, uzhas, Вы писали:

EP>>Покажи как бы выглядел код использующий Asio с этими хэндлерами.
U>например, так:
U>

U>    m_socket.close();
U>    m_ConnectTask.wait(); //blocks if there is incomplete async op, non blocking if there is no associated async op
U>

А каков механизм блокирования? Там могут быть разные случаи:

1. Всё происходит в одном потоке, в котором запущен io_service.
Заблокировать поток нельзя, так как тогда не выполнится хэндлер — получаем deadlock. Нужно внутри wait'а крутить io_service, например через run_one. Но, если соединений очень много, и каждое будет делать такой wait, можем запросто получить stackoverflow — конечно можем увеличить адресное пространство стэка, но как-то получается не айс.

2. В одном потоке запущен io_service, а ждать нужно в другом, в котором он не запущен. Здесь достаточно future.

3. Есть два потока, в каждом из которых крутится свой io_service, либо один и тот же. Полностью блокировать плохо, нужно крутить run_one — что опять же может привести к stackoverflow.

EP>>Часто нужен не явный контроль, а всего лишь prompt finalization, который прекрасно обеспечивается RAII.
U>я не вижу, как RAII поможет в примере выше. более того, socket.close — это не RAII, однако без него было бы еще сложнее =)

socket.close это действительно не RAII. RAII помогает освободить ресурсы в этих хэндлерах после этого явного close, причём как promt finalization.

EP>>Не надо раздавать shared_ptr кому попало.
U>дисциплину тяжело крыть автотестами,

Можно ограничивать доступ через private.

U>нужны более понятные средства, помогающие писать надежный софт

Проблема с ресурсами в контексте асинхронных обработчиков есть и в GC языках — там это один из основных use-case'ов для утечек, только помимо этого ещё и отсутствует нормальное promt finalization.

EP>>Если в какой-то точке программы (в другом потоке?) нужно дождаться момента разрушения какого-то объекта, то необходимо делать блокирующее ожидание.
EP>>Ты ссылаешься на то continuation, которое подразумевается в call-with-current-continuation. Есть же второе значение, которое в подразумевается в continuation-passing style.
U>в CPS тоже речь не о колбеке, а о целой ветке исполнения

Так при использовании Asio тоже приходится делать целую ветку исполнения.

EP>>Я считаю что вполне уместно называть хэндлер асихнронной операции продолжением — это уже устоявшаяся практика.
U>а я считаю наоборот, это плохая практика, также как и писать "длинна", хоть это и распространенная практика

У тебя может есть ссылка на значимый первоисточник, в котором чётко написано что такое handler, а что такое continuation?
Если такого каноничного источника нет, то и приходится опираться на распространенную практику

Здравствуйте, uzhas, Вы писали:

EP>>Покажи как бы выглядел код использующий Asio с этими хэндлерами.
U>например, так:
U>

U>    m_socket.close();
U>    m_ConnectTask.wait(); //blocks if there is incomplete async op, non blocking if there is no associated async op
U>

А каков механизм блокирования? Там могут быть разные случаи:

1. Всё происходит в одном потоке, в котором запущен io_service.
Заблокировать поток нельзя, так как тогда не выполнится хэндлер — получаем deadlock. Нужно внутри wait'а крутить io_service, например через run_one. Но, если соединений очень много, и каждое будет делать такой wait, можем запросто получить stackoverflow — конечно можем увеличить адресное пространство стэка, но как-то получается не айс.

2. В одном потоке запущен io_service, а ждать нужно в другом, в котором он не запущен. Здесь достаточно future.

3. Есть два потока, в каждом из которых крутится свой io_service, либо один и тот же. Полностью блокировать плохо, нужно крутить run_one — что опять же может привести к stackoverflow.

EP>>Часто нужен не явный контроль, а всего лишь prompt finalization, который прекрасно обеспечивается RAII.
U>я не вижу, как RAII поможет в примере выше. более того, socket.close — это не RAII, однако без него было бы еще сложнее =)

socket.close это действительно не RAII. RAII помогает освободить ресурсы в этих хэндлерах после этого явного close, причём как prompt finalization.

EP>>Не надо раздавать shared_ptr кому попало.
U>дисциплину тяжело крыть автотестами,

Можно ограничивать доступ через private.

U>нужны более понятные средства, помогающие писать надежный софт

Проблема с ресурсами в контексте асинхронных обработчиков есть и в GC языках — там это один из основных use-case'ов для утечек, только помимо этого ещё и отсутствует нормальное prompt finalization.

EP>>Если в какой-то точке программы (в другом потоке?) нужно дождаться момента разрушения какого-то объекта, то необходимо делать блокирующее ожидание.
EP>>Ты ссылаешься на то continuation, которое подразумевается в call-with-current-continuation. Есть же второе значение, которое в подразумевается в continuation-passing style.
U>в CPS тоже речь не о колбеке, а о целой ветке исполнения

Так при использовании Asio тоже приходится делать целую ветку исполнения.

EP>>Я считаю что вполне уместно называть хэндлер асихнронной операции продолжением — это уже устоявшаяся практика.
U>а я считаю наоборот, это плохая практика, также как и писать "длинна", хоть это и распространенная практика

У тебя может есть ссылка на значимый первоисточник, в котором чётко написано что такое handler, а что такое continuation?
Если такого каноничного источника нет, то и приходится опираться на распространенную практику