<br><br><div class="gmail_quote">13 января 2011 г. 11:52 пользователь Dmitry Karasik <span dir="ltr"><<a href="mailto:dmitry@karasik.eu.org">dmitry@karasik.eu.org</a>></span> написал:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> появляется проблема что если один процесс "схватил" несколько клиентов, а<br>
> один из них требует выполнения ресурсоемкого задания, то другой клиент будет<br>
> ждать, хотя мог бы быть обработан<br>
<br>
</div>а пусть не хватает несколько, каждый пусть берет по одной задаче, а главный процесс<br>
распределяет по необходимости, возможно форкая новые или убивая бездеятельные </blockquote><div><br>ну да, что-то такое примерно и рисуется.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
> но тут встает задача быстрой передачи данных задания в другой процесс.<br>
> сериализация/десериализация сама по себе может оказаться довольно накладной<br>
> вещью и возвращаемся к тому с чего мы начали. > А есть ли способ (может на<br>
> базе mmap кто-то делал решение?) быстрой передачи объекта perl между двумя<br>
> процессами? И вообще, кто решал подобные проблемы, поделитесь соображениями?<br>
<br>
</div>я не знаю таких способов, но по идее, если есть нужда между главным процессом и обработчиками<br>
гонять страшные гигабайты, но может тогда просто исключить из цепочки главный процесс?<br>
пусть обработчики сами вычитывают большие данные.<br></blockquote></div><br>это по сути возврат к форковой модели. гигабайты не страшные, но простая сериализация объекта о сотне К может уже давать ощутимый оверхед. <br>