Pull to refresh

Comments 24

Очень любопытно. Я раньше слышал про эту фичу, но как-то руки и глаза не доходили документацию прочитать. Кажется, я уже даже знаю, где это можно применить, так что, спасибо.
Главное с умом применять асинхронность. Иногда её применяют совсем не к месту. Статья понравилась, только все же код лучше подсвечивать.
Да, интересно.
А не знаете, есть ли что-то похожее для PHP?
Я не встречал. Но я думаю, что в механизма наверно лежит работа с pipes.
нет :-) скорее с асинхронными сокетами
Есть. pg_send_query и другие функции для асинхронных запросов. Правда, глубинное понимание того, как они работают, приходит, скорее, не после чтения мануала, но на собственном опыте. Впрочем, иногда оно того стоит
UFO just landed and posted this here
дружит. Единственное что — после отмены выполнения запроса транзакция ломается. Советуют выполнить ROLLBACK.
UFO just landed and posted this here
при чём тут это?

есть конечно? POE, например.
только тут о других вещах говорит автор топика
UFO just landed and posted this here
ну это другой подход опять же… тут объясняется про схему:

отправили запрос
делаем какие либо действия не трубующие результата этого (или этих если им много) запроса
когда понадобился результат: получаем ответ
обрабатываем ответ

Результат тот же, только многим людям понятнее чем callback'и
(Я не против callback'ов! В javascript их очень неплохо реализую и люблю использовать, программа симпатичней и логичнее получается, но это не для всех)
Просто тут другая парадигма.
кстати, опять же, используя threads.pm можно легко воплотить callback функционал
async callback функционал,
правда ниже 528depp написал оптимальное решение
В первую очередь стоит обратить внимание на AnyEvent::DBI. Правильно было написано выше что смысл асинхронности в вызове коллбэка, а не проверок в стиле «Ну что готово?» "-Нет" «Так, а сейчас может быть готово?».
AnyEvent::DBI создаёт ещё один поток. По своему опыту могу сказать — в Perl с потоками лучше не работать, если не хотите искать, почему ваша программа умерла с segmentation fault…
Насчет потоков — согласен, только AnyEvent::DBI создает не поток, а процесс, тоесть fork'ается.
ага. Создавать по процессу на соединение тоже не очень:
The overhead for very simple statements («select 0») is somewhere around 120% to 200% (dual/single core CPU) compared to an explicit prepare_cached/execute/fetchrow_arrayref/finish combination.
Вся проблема в том, что DBI не умеет работать асинхронно. Иногда можно забить на DBI и опустить на уровень DBD::Pg
Секунду, а причем тут процесс на соединение? Что вам мешает использовать один и тот же $dbh? Я понимаю что это решение не подойдет для web, но автор топика (вы) и не говорил про то что это конкретная заточка под web, как я понимаю речь идет об общем асинхронном программировании баз данных в Perl.
У меня много скриптов демонов висит которые используют именно AnyEvent::DBI.
Overhead в 120-200% я считаю очень даже допустимым, тока что набросал bechmark, 10к запросов «select 1», результат:
DBI (with explicit prepare): 0.688
DBI (with prepare in loop): 1.180
AnyEvent::DBI: 2.785
Возможно иногда и можно забить. Иногда нельзя, зависит от ситуации.
Ну кстати под линуксом у меня вроде стабильно работали (без shared данных). Только вот расход памяти большой.
запускай потоки не от main пакета, будут маленькие, т.е. создавай отдельный package для запуска потоков
Попробую, спасибо. Хотя, мне не кажеся, что это поможет.
В потоке запускается целый интерпретатор. Даже если делать отдельный пакадж, удаляя тем самым все локальные данные из контекста, все равно многовато получится. Тем не менее попробую померить.
стоит посмотреть также AnyEvent::DBD::Pg
Да, AnyEvent::DBD::Pg был написан буквально месяц назад, использует эту фичу и лучше всего подходит для этой задачи.
Sign up to leave a comment.

Articles