> Я бы ни кому не рекомендовал связываться с Coro.
> Coro по ощущениям от использования весьма нестабильная штуковина. Во многом > потому что ядро перла ничего о Coro не знает и код Coro по большому счету > набор костылей. Вероятность поломки при выходе новой версии интерпретатора > всегда отлична от нуля. Делать ставку на такой инструмент, по моему, не > правильно. > P.S. cede в отличие от yield return ничего не возвращает. у меня несколько продакшенов на Coro. вот один из них держит 10К http запросов (реальных, не бенчмарковых) на ядро. я не встречал в Coro нестабильностей. Хотя начали мы его юзать в эпоху Perl 5.10, сейчас вот есть один продакшен на 5.18 есть некоторые вещи о которых нужно знать когда юзаешь Coro это да, например - каждая Coro веточка выполняется со своим стеком 8К. это накладывает ограничения на размер убиваемого объекта (в Perl деструкторы рекурсивные и поэтому если у вас большой скажем двусвязный список, то в деструкторе может вылезти по рекурсии за 8К и получить SIGBUS) - есть несовместимости apache(mod-perl) и многих других embedded-perl решений с Coro (но у этих решений есть несовместимости например и с AnyEvent, с EV итп) - короче асинхронники либо писать самостоятельные, либо хорошо покрывать _интеграционными_ тестами что делаете - (не касается Coro в частности, а скорее асинхронников вообще) - когда юзаете сторонние либы и пишете свои - нужно тщательно следить за мемликами ну а когда проект большой то рано или поздно возникают задачи доступа к одной сущности с разных сторон: например из под блокирующего вебсервера и из асинхронного демона (одного-пяти). и если вы пишете на AE, то вы делаете модели которые для AE и модели которые для синхронного варианта. в случае с Coro можно делать эти модели одними и теми же сущностями. (в общем случае за несколько лет работы с Coro, я слово cede ни разу и не написал ни в одном приложении: правильно написанный асинхронник не должен заниматься возней с шедулером.) -- Moscow.pm mailing list [email protected] | http://moscow.pm.org
