Если сравнивать брокеры сообщений — они все примерно похожи на AMQP. Если смотреть на другие варианты очередей (beanstalkd, Kafka, и т.п.) — это другие решения с другими характеристиками. ØMQ — обмен сообщениями без брокера.
Лучше смотреть на картинку «Deferred в квадрате», и рассматривать Deferred2 как отдельный поток, который начинается выделением ресурса (т.е. к моменту прихода на уровень callback2_1 ресурс уже выделен).
У Deferred есть метод .addBoth, который добавляет один и тот же обработчик на оба слота (callback/errback) на одном уровне. Это модель try...finally, который и используется для гарантированного освобождения ресурса при любом исходе.
Мой комментарий относился ни к скорости создания нитей, ни к красоте кода.
В общем случае, чистый код в нитях (без другой модели программирования, например Actor в Erlang) крайне труден в поддержке/разработке из-за наличия тех или иных синхронизаций, число которых для получения приемлемой скорости растет.
Дело было примерно так — автор Tornado пытался понять Twisted, писал в список рассылки, спрашивал. Но так и не понял и сделал Tornado. Видимо, такова его ниша (Tornado) и такое «упрощенное» решение имеет право на существование.
Без обид. Просто другой взгляд на вещи.
Поэтому я думаю сравнение технологий без определения критериев и конкретных метрик бесмысленно.
Уточню: гораздо меньший битрейт за счет использования хорошего кодека, и возможность экспортировать записанные видео в родную Фотогаллерею айФона — где появляется возможность тримить видео и загружать его на РС.
А так вообще на джейлбрекнутых айФонах можно пользоваться намного лучшим API по захвату видео, соотв. FPS (кадров в секунду) там всегда будет лучше пока Apple нормальный API не откроет.
На самом деле это не такой маленький список. Для работы Qik нужна в телефоне качественная камера, а для live неплохой канал: WiFi/3G/Edge. Поэтому поддержать совершенно любой телефон смысла нет, но мы постоянно занимаемся расширением перечня моделей телефонов, на которых Qik работает.
Мне трудно сказать, я не эксперт в Erlangе, знаю, что там замечательный внутренний messaging. Чаще всего рано или поздно придется интегрироваться с другими системами, написанными на чем-то еще. И вот тогда «прослойка» в виде AMQP-брокера может очень даже пригодится.
P.S. RabbitMQ (AMQP-брокер) как раз написан на Erlang.
«Чтобы вытащить 5 пакетов из зеркала», можно сделать примерно так:
aptly выкачает только пакеты, которые удовлетворяют условиям фильтра, полный синтаксис здесь.
У Deferred есть метод .addBoth, который добавляет один и тот же обработчик на оба слота (callback/errback) на одном уровне. Это модель try...finally, который и используется для гарантированного освобождения ресурса при любом исходе.
В общем случае, чистый код в нитях (без другой модели программирования, например Actor в Erlang) крайне труден в поддержке/разработке из-за наличия тех или иных синхронизаций, число которых для получения приемлемой скорости растет.
То есть на верхнем уровне это скорее различие языков и философий программирования, определяемых языком.
Вообще говоря Ruby MRI на сегодня медленнее Python.
Может, кто из пробовавших оба расскажет?
Без обид. Просто другой взгляд на вещи.
Поэтому я думаю сравнение технологий без определения критериев и конкретных метрик бесмысленно.
А так вообще на джейлбрекнутых айФонах можно пользоваться намного лучшим API по захвату видео, соотв. FPS (кадров в секунду) там всегда будет лучше пока Apple нормальный API не откроет.
P.S. RabbitMQ (AMQP-брокер) как раз написан на Erlang.