$3M инвестиций в NGINX.
Deep C (and C++) (сегодня запостили на RSDN) - каждый слайд, что называется, "в яблочко".
Overload 105 (см. Picking Patterns for Parallel Programs). Asio samples == almost C++ actors based on task based (fork/join) parallelism.
вторник, 11 октября 2011 г.
пятница, 30 сентября 2011 г.
Весёленький год
Мда. Этот год, наверное, поставил рекорд по остроте новостей с IT-фронта:
1. Nokia отвернулась от MeeGo и ищет спасения под крылом MS WP7
2. HP – рыба гниет с головы
3. Intel, что вы там курите? (комментарии особенно хороши)
Очень жаль, и Qt (в т.ч. соотв. подразделение Nokia) и MeeGo.
1. Nokia отвернулась от MeeGo и ищет спасения под крылом MS WP7
2. HP – рыба гниет с головы
3. Intel, что вы там курите? (комментарии особенно хороши)
Очень жаль, и Qt (в т.ч. соотв. подразделение Nokia) и MeeGo.
суббота, 10 сентября 2011 г.
timer revisited
В выложенной недавно версии 0.3.5 реализован "канонический" вариант работы с таймером (ma::echo::server::session). Данный вариант принципиально отличается от предыдущего (!). В прошлом я намеренно сужал API asio::deadline_timer до Java-вского ScheduledExecutorService, дабы иметь в кармане решение и для Java. Однако, с asio::deadline_timer можно работать эффективнее.
Нужно заметить, что мой варинт отличается от того, что предложил автор Asio:
1. нет таких "подвывертов", как deadline_.expires_at(boost::posix_time::pos_infin);
2. нет явных обращений к now(): deadline_.expires_at() <= deadline_timer::traits_type::now().
3. все обыгрывается за счет двух булевых флагов - их можно было заменить одной переменной с тремя состояниями, но с флагами получилось читабельнее.
P.S. А для ScheduledExecutorService можно сделать все в точности так же и никакого "сужения" не нужно было вовсе 8)
Нужно заметить, что мой варинт отличается от того, что предложил автор Asio:
1. нет таких "подвывертов", как deadline_.expires_at(boost::posix_time::pos_infin);
2. нет явных обращений к now(): deadline_.expires_at() <= deadline_timer::traits_type::now().
3. все обыгрывается за счет двух булевых флагов - их можно было заменить одной переменной с тремя состояниями, но с флагами получилось читабельнее.
P.S. А для ScheduledExecutorService можно сделать все в точности так же и никакого "сужения" не нужно было вовсе 8)
понедельник, 5 сентября 2011 г.
echo_server revisited
Наконец-то закончен "канонический вариант" активного объекта - ma::echo::server::session и ma::echo::server::session_manager.
Единственное по-настоящему важное изменение – это введение явных раздельных state machine (КА) для внешней части активного объекта (proxy) и для внутренней части (implementation). Так же явно введены КА для каждого вида internal activities. При этом код стал визуально чище и проще (на днях заглянул в код Qt - бр-р-р).
Удалось обойтись без Boost.MSM. Пока я не вижу, чем могла бы помочь данная библиотека, т.к. налицо несколько взаимосвязанных КА, либо какой-то combinatorial FSM.
P.S. Из-за загруженности на основной работе впопыхах пропустил пару глупых ошибок как в коде/логике, так и в комментариях – поэтому текущая версия уже 0.3.5.
Единственное по-настоящему важное изменение – это введение явных раздельных state machine (КА) для внешней части активного объекта (proxy) и для внутренней части (implementation). Так же явно введены КА для каждого вида internal activities. При этом код стал визуально чище и проще (на днях заглянул в код Qt - бр-р-р).
Удалось обойтись без Boost.MSM. Пока я не вижу, чем могла бы помочь данная библиотека, т.к. налицо несколько взаимосвязанных КА, либо какой-то combinatorial FSM.
P.S. Из-за загруженности на основной работе впопыхах пропустил пару глупых ошибок как в коде/логике, так и в комментариях – поэтому текущая версия уже 0.3.5.
Золотые слова
Цитата из этой статьи с Хабра:
На самом деле, принятие гибридного подхода к параллелизма, кажется, является движением вперед, если нет каких-либо противопоказаний. Ученые в области компьютерных наук из университета штата Пенсильвания обнаружили, что сочетание потоков и событий предлагает лучшее из обоих миров. Команда Scala в EPFL утверждает, что Actors объединяют программирование на основе потоков выполнения и программирование на основе событий в одну аккуратную, простую для понимания, абстракцию. Russ Cox, бывший сотрудник Bell Labs, теперь занятый проектом языка программирования Go в Google, заходит ещё дальше, утверждая, что бессмысленна сама дискуссия „потоки против событий“ (обратите внимание, что все это даже не затрагивает аспект распределения масштабирования системы; потоки — это конструкции для одного компьютера, и события, — конструкции для одного процессора; мы даже не говорим о распределении работы между машинами в простой манере; кстати, это включено в Erlang, и о нём стоит задуматься, если вы няньчите быстро растущую систему).Именно к active object/actor (на уровне, максимально облегченном в плане прослоек) я и стремлюсь. Кто-нибудь может сравнить echo_server с Erlang-style в плане параллелизации? И что это за проект на китайском?
воскресенье, 24 июля 2011 г.
Re: The last of the Boostcon videos
Наконец-то я полностью посмотрел последний доклад Christopher Kohlhoff Why C++0x is the Awesomest Language for Network Programming на BoostCon 2011. До этого я лишь бегло пробежался по нему и сделал вывод, что ничего нового там для меня нет.
И действительно, все, что прозвучало в докладе, давно есть в блоге автора и в Boost.Asio 1.5.3 (а теперь и в Boost 1.47). Подумать только, stackless coroutines были анонсированы (dev версия, так и не вошедшая в Boost.Asio) еще в 2009 году, а о поддержке move semantic для completion handlers я просил еще с момента прочтения статьи Onward, Forward! Dave Abrahams (и реализовал ее в asio samples раньше, чем она официально появилась в Boost.Asio). Но как же здорово, что есть возможность почти вживую послушать автора и его комментарии к исходному коду (а заодно и оценить юмор как самого автора, так и его слушателей). Спасибо, Marshall Clow. Появились бы эти (известные всем подписчикам рассылок по Boost) видеозаписи докладов, если бы не он?
Что ж, BoostCon 2011 закончен. Сенсаций от автора Asio не прозвучало. Да и нужны ли они на таком мероприятии? Скорее "нет", чем "да". Судя по тем немногочисленным вопросам из зала, рассказать слушателям про возможности Boost.Asio было все же важнее. Теперь ждем BoostCon 2012 и надеемся вновь увидеть автора Asio. Учитывая объем изменений, вошедших в Boost 1.47, можно сказать, что Boost.Asio активно развивается (ну или точно не стоит на месте). Значит, Крису будет о чем рассказать нам в следующий раз. Может стоит предложить ему несколько тем? Я мог бы предложить рассказать подробнее о custom memory allocation и соответствующих hook-функциях для привязки к handler. Или раскрыть тему asio_handler_invoke. А Вы?
И действительно, все, что прозвучало в докладе, давно есть в блоге автора и в Boost.Asio 1.5.3 (а теперь и в Boost 1.47). Подумать только, stackless coroutines были анонсированы (dev версия, так и не вошедшая в Boost.Asio) еще в 2009 году, а о поддержке move semantic для completion handlers я просил еще с момента прочтения статьи Onward, Forward! Dave Abrahams (и реализовал ее в asio samples раньше, чем она официально появилась в Boost.Asio). Но как же здорово, что есть возможность почти вживую послушать автора и его комментарии к исходному коду (а заодно и оценить юмор как самого автора, так и его слушателей). Спасибо, Marshall Clow. Появились бы эти (известные всем подписчикам рассылок по Boost) видеозаписи докладов, если бы не он?
Что ж, BoostCon 2011 закончен. Сенсаций от автора Asio не прозвучало. Да и нужны ли они на таком мероприятии? Скорее "нет", чем "да". Судя по тем немногочисленным вопросам из зала, рассказать слушателям про возможности Boost.Asio было все же важнее. Теперь ждем BoostCon 2012 и надеемся вновь увидеть автора Asio. Учитывая объем изменений, вошедших в Boost 1.47, можно сказать, что Boost.Asio активно развивается (ну или точно не стоит на месте). Значит, Крису будет о чем рассказать нам в следующий раз. Может стоит предложить ему несколько тем? Я мог бы предложить рассказать подробнее о custom memory allocation и соответствующих hook-функциях для привязки к handler. Или раскрыть тему asio_handler_invoke. А Вы?
четверг, 7 июля 2011 г.
Client-side Boost.Asio: быть или не быть? ;)
Предлагаю читателям обсудить в комментариях к этому сообщению следующую тему: стоит ли использовать Boost.Asio на стороне клиента. С серверами все понятно - там вменяемой альтернативы (на C++) нет. А вот с клиентами как?
Для "затравки" мое мнение: то, что клиенты до сих пор не используют асинхронный ввод/вывод - "дело времени" и связано с привычкой и ленью.
Да, можно выделить весь синхронный ввод-вывод в отдельный поток (thread). Но (!) как Вы собираетесь передавать данные в этот поток и получать данные из него? Конечно же через очереди. Ага, получаем как раз тот вариант (io_service + io_service::strand), что описан в проекте nmea_client. Т.е. без Asio это будет просто очередной "велосипед".
Я могу ошибаться. Мне очень интересны (контр)аргументы противоположной стороны. Буду рад их услышать и сделать какие-то выводы для себя.
Для "затравки" мое мнение: то, что клиенты до сих пор не используют асинхронный ввод/вывод - "дело времени" и связано с привычкой и ленью.
Да, можно выделить весь синхронный ввод-вывод в отдельный поток (thread). Но (!) как Вы собираетесь передавать данные в этот поток и получать данные из него? Конечно же через очереди. Ага, получаем как раз тот вариант (io_service + io_service::strand), что описан в проекте nmea_client. Т.е. без Asio это будет просто очередной "велосипед".
Я могу ошибаться. Мне очень интересны (контр)аргументы противоположной стороны. Буду рад их услышать и сделать какие-то выводы для себя.
Подписаться на:
Сообщения (Atom)