Если в курсе про Cyclone, есть вопрос: сильно ли Cyclone отстает от Tornado по фичам и производительности? Не пробовал ни то, ни другое, хочу Cyclone мне нравится гораздо больше из-за использования отделимого event loop
Собственно, ваш первый аргумент решающий. В пользу циклона. И да, оно не «нативное» и не «встроенное», а обусловлено использованием twisted, для которого реализованы эти протоколы. Cyclone — просто реализация ещё одного протокола http. И даже при незначительном отставании в производительности я выберу его из-за интероперабельности и следования unix-way, если мне не подскажут других проблем с Cyclone :)
нет. у нас целиком websockets приложение. никаких flash клиентов.
невидимая flash-прокладка используется только в случае устаревшего браузера, не поддерживающего ws протокол для его (протокола) эмуляции.
или включите websockets в ff4 (что более предпочтительно), или установите свежий flash на него. галочка соединения слева сверху должна гореть зеленым. (в у нее в title можно увидеть используется ws native или flash emulation)
ага, и инструкции в помощи увидел… было бы здорово чтобы пользователям у кого это не сделано, выскакивало соответсвующее предупреждение, а то как-то не интуитивно получается.
В том то и дело что умеем. Опыт плотной работы с twisted около 5 лет. Если вы прочитаете статью внимательнее, вы поймете что серебрянной пули (кто бы сомневался) в очередной раз нет, и нужен выбор между несколькими моделями обработки событий. tornado этот выбор дает просто и эффективно. twisted в общем-то тоже дает, но он тянет за собой изрядный кус слоя совместимости, и все получается гораздо более громоздко и неочевидно, да еще и лишними зависимостями.
А почему вы решили, что я читал ее невнимательно? И потом — что такое «лишние зависимости»? Gnome? KDE? Что такое «изрядный кус слоя совместимости»? В чем громоздкость?
Вы изложите конкретно, раз уж вы реверанс в сторону твистед сделали — хаете, хайте аргументировано.
А пока пяти лет опыта незаметно.
Торнадо все таки web-фреймворк, пусть и не сильно раскачанный. А eventlen и gevent для работы с конкретно web средств практически не имеют. Поэтому сравнивать не вполне корректно, я считаю.
Насчет ThreadableMixin что-то пугает стартовать треды на каждый start_worker()… Может все-же пул завести и очередь?
Вот последние пару недель задумывался над следующим вопросом — как мне из main thread в которой крутится event_loop и слушаются сокеты передать задание воркеру (воркер в отдельном потоке) и получить обратно от него результат не выполняя callback в треде воркера?
Пока в голову приходит только 2 очереди. Одна очередь для передачи данных от main_thread к воркерам и вторая для передачи данных от воркеров к main_thread. Причем main_thread проверяет поступили ли к ней данные в очередь на каждом обороте EventLoop в неблокирующем режиме и если поступили — обрабатывает. Единственная проблема — проверять поступление данных в очередь нужно как можно чаще, соответственно придется делать холостые обороты в EventLoop…
Собственно вопрос — может ли worker_thread как-то добавлять свои события в EventLoop?
Вы совершенно правы. В реальной системе конечно же пул очередей. Здесь он опущен чтобы не добавлять в код громоздкости.
из worker_thread добавлять свои события в EventLoop теоретически можно, но лучше так не делать. Лучше добавить их уже в results() после отработки потока.
1. мне больше gevent нравиться.
2. А разве от websockets не отказались (из-за проблем с уязвимостью)? Они вроде сейчас включены по умолчанию только в Chrome.
Этот код при любом запросе ajax или get/post просто сделает редирект на страницу, к которой был сделан запрос, отобразив self.res в окне браузера, вместо того чтобы вернуть переменную инициатору запроса.
Многопоточное приложение под Tornado