Да не... Я думал как именно SV в шаред память засунуть через манкирование аренами в перле.

Там проблема в том, что рефкаунтер сидит в самой SV. Если-бы он был не там, то copy-on-write сработал-бы.

А так я наткнулся на то, что у тебя в SV сидит ссылка на стеш объекта и надо решать проблему поинтеров. В принципе она решаемая... Надо просто прокси классы делать так, чтобы они смотрели в не шаренную, но одинаковую по поинтеру память и в ней уже располагать эти прокси классы.

Но дальше этого у меня времени не хватило.

Какой-то "холодный термояд" :) Кстати, когда думал на тему "скрестить perl и многопоточность" нашёл хороший гибридный вариант - как сделали в node/JS: там сделали возможность типа RPC через разделяемую память. Т.е. основной евентлуп у них однопоточный, но благодаря этой фиче можно легковесно оффлоадить обработку на вебворкеры.

Ну многопоточный и перл - это несовместимые вещи, а насчет хитрого термояда - да... Там все весело.

Ну, многопоточность - это средство. А цель - легковесная передача информации между задачами ОС.

Короче... Возвращаясь к твоей задачи. Нужен вотчдог, который будет поднимать процессы. На одной или нескольких тачках - это все равно. Главное чтобы их было кратно количеству шар (количество шар сам выберешь). Так-же нужны аггрегаторы, которые равномерно будут размазывать нагрузку по шарам (на самом деле каждый аггрегатор будет подключен к своему набору уникальных шар). Все аггрегаторы сажаешь на одну тачку, которая будет шлюзом. Аггрегаторы слушают вход и потом перераспределяют запросы (кстати, всегда надо все блоки проверять или до первого удачного? Если последнее, то как равномерность удачности сделали?).

Это работает криво, если надо уметь произвольную очередь задач и воркер "тупит".

выбираются все блоки удовлетворяющие условиями выборки

Ну тогда и проблемы нету.

Я-бы рекомендовал тогда уж взять в качестве сервера наш UniEvent::TCP / UniEvent::HTTP::Server (В последнем вебсервера нету, но он быстрый). Только если будешь брать HTTP, то не бери UniEvent::HTTP::Manager, а то он тебе нафоркает еще.

http я не хочу. просто буду слать упакованный контекст

Как знаешь. Тут http быстрый, так как все написано на плюсах.

ну может и так, я погляжу

А вот что взять в качестве вотчдога - это вопрос... И как это все друг с другом связывать.

Что значит "произвольную очередь задач"? Внутри воркера может быть та же неблокирующая обработка. Либо часть воркеров может быть отведено под блокирующие операции (например, доступ к БД через DBI).

Но такая организация подразумевает, что в приложениях, использующих её, будет различие между обработчиками для основного евентлупа (через который приложение общается с внешним миром) и для воркеров - хотя можно реюзать какие-то части в обоих частях. Но вот так можно обойти то, что рантайм языка проектировался без возможности эффективной многопоточной работы.

Это-то как раз легко. Ты так или иначе всегда возвращаешься в эвент луп. И перед тем как уйти в сон надо еще слушать семафоры...

Угу - слушать семафоры и передвать данные между процессами через циклические буфера в разделяемой памяти.

Вот вопрос что ты будешь делать если циклический буфер забился? Домапливать память?