внимательно не рассматривал, но интуитивно не очень.. 

запустите код из этой темы под профайлером. и сами посмотрите на результат. не думаю что профайлер врет.


это интересный момент..

принимать может ( http://liveworkspace.org/code/93c25ddc57b2...c6880d858a56139 )
удаляет неправильно (без [])

Вы просто забыли, что такое шаблон Proactor и как важен для него механизм, предоставляемый Boost.Asio: custom memory allocation (http://www.boost.org/doc/libs/1_46_1/doc/html/boost_asio/overview/core/allocation.html)

С этим механизмом (с его применением) Вы сильно удивитесь резвости asio, так как в этом случае все аллокаци во всех используемых очередях (io_service, io_service::strand, deadline_timer) могут свестись к банальному:

mabrarov, Марат, здравствуйте ;)
по приведенной вами ссылке, читал, и не раз.
не могли бы Вы популярно объяснить, и, желательно с примером. буду сильно благодарен.
спасибо.


Это сообщение отредактировал(а) boostcoder - 13.4.2011, 02:13

А я думал, что уже достал Вас    

Объяснить проще, чем в примерах Boost.Asio, я не смогу. К сожалению, проще уже некуда.
Могу только пояснить следующее: как любая система построенная по шаблону Proactor (да и вообще - как все многопоточные системы, базирующиеся на очередях - т.е. почти все более-менее "продвинутые" многопоточные системы, например, Intel TBB), asio активно использует очереди (в случае asio - это очереди из функциональных объектов). 

В связи с этим остро встает вопрос выделения памяти в таких очередях (особенно остро в свете многопоточности и кешей процессора). Intel TBB решает это своим "прокаченным-специализированным" аллокатором (и обещаниями повторно использовать выделяемые блоки). 

asio использует очень легкое и гибкое решение (и это не единственный случай!): позволяет использовать allocator per async operation (начиная с dev release 1.53 - во всех асинхронных операциях). И вот какая штука: в любом вменяемом (т.е. не "hello world") приложении количество одновременных однотипных асинхронных операций над одним и тем же объектом (например, socket или deadline_timer) всегда ограничено сверху. И зачастую это ограничение равно единице (Вы уже на него нарвались недавно).

Исходя из всего вышесказанного, зачастую, Вы можете просто заранее выделить непрерывный блок памяти, который будет удерживаться Вашим handler-ом (например, при помощи shared_ptr). Затем, каждый раз когда asio будет нужна память для чего-то временного (обычно, это память для расположения в очереди - IOCP или boost::asio::io_service::strand или даже deadline_timer), что связанно с асинхронной операцией, для которой Ваш handler является completion handler-ом - asio просто попросит об этом через Ваш же handler. При этом те гарантии что дает asio относительно custom memory allocation, гарантируют, что (при достаточном размере Вашего пред-аллоцированного блока памяти) Вы всегда сможете выделить  эту память из того самого, ранее выделенного, блока памяти.

Кроме того, гарантии asio позволяют удерживать этот "пред-аллоцированный блок памяти" самим же handler-ом (с небольшим ограничением на handler - см. доки по Boost.Asio 1.53, почти всегда это ограничение выполняется и уж точно всегда его можно легко обойти). Главное, хранить в handler-е не сам блок, а указатель на него (лучше -smart) - чтобы в блок помещался сам handler + что-то временное.

В моем проекте (http://sourceforge.net/projects/asio-samples) echo_server (и qt_echo_server, и, вообще, все "asio samples") вообще не выделяет память в куче при своей непосредственной работе (кроме приема новых входящих TCP-соединений, да и тут есть reuse). Custom memory allocation сводит все выделения памяти к тому коду, что я указал - т.е. никаких блокировок и даже никаких атомарных (interlocked) операций. Плюс, в теории (не могу до сих пор проверить) - это должно очень положительно сказаться на использовании CPU-кеша (+ учтите очень правильную реализацию strand-ов в asio).

Это сообщение отредактировал(а) mabrarov - 13.4.2011, 02:16

возможно я не туда смотрю..
вот дока asio-1.4.9 входящая в состав boost-1.46.1: http://www.boost.org/doc/libs/1_46_1/doc/h...allocation.html
а вот дока asio-1.5.3 с офф. сайта: http://think-async.com/Asio/asio-1.5.3/doc...allocation.html

не вижу разницы.
или я не туда смотрю?

Вот и я не увидел. Но в release notes к asio-1.5.3 все четко сказано. А уж в коде я сразу "порылся" 8) - ждал этого с самого рождения asio.
Не увидел и написал Christopher M. Kohlhoff об этом. Он вежливо поблагодарил за замеченную неточность и... ничего не исправил.

  
"великий OpenSource" (с)

остается ждать.

К слову, документация у Christopher M. Kohlhoff ну просто очень и очень хорошая (только надо не забывать, что примеры в ней тоже являются обязательным чтивом). 
Думаю:
1) когда asio-1.5.3 войдет в Boost C++ Libraries, все будет исправлено;
2) сразу после выхода asio-1.5.3 Chris уже должен был готовиться к BoostCon 2011;
3) судя по тому, что я читал в рассылке asio-users, он действительно занят коммерческими проектами, остается только поражаться тому, как он находит время и силы и вносит столь серьезные (и долгожданные) изменения, как move semantic support и custom memory allocation support for SSL async operations. 

не могу согласиться. увы :(

полагаю, сейчас отпишется не один программист, разделяющий мою точку зрения ;)
ибо я такое слышу каждый день(ну почти) от знакомых и коллег.

Радует, значит про Asio на просторах СНГ слышали и даже используют.
А если чего-то в документации Asio не хватает, то... для этого и существуют asio samples. Дай бог времени и желания - напишу пару статей на русском про наиболее частые ошибки разработчиков, пытающихся использовать Asio вопреки определенным в документации ограничениям/гарантиям.
Ну и да, это Open Source (и даже не GPL) - поэтому прежде чем переводить production code на Boost.Asio я внимательно изучал его исходники. Это многое открывает, особенно в плане понимания производительности Asio в сравнении с "raw WinSock".
Сравните документацию по Boost.Asio с документацией по ACE или даже с книгами по ACE.

вставьте-ка лучше ссылку в подпись. найти будет легче. и, возможно, гугл проиндексирует.


когда я только начал постигать _network_programming_in_c++_, я пересмотрел несколько библиотек, и ACE одна из них. но от нее я отказался, в виду монструозности. поэтому не юзал. и о качестве документации вряд-ли смогу сказать уверенно.