решил проблему. Нужно сделать просто downgrade с 2.000001 на 1.86
и всё работает

может https://metacpan.org/pod/Alias ?
есть еще https://metacpan.org/pod/aliased

так и не переписали на php? =)

😂

> А у перла с шаред памятью все плохо

Что за шаред память? Использование одной памяти для разных процессов? Мемкешд ж выручает вроде. Ну ещё про какие-то там редисы "краем уха" слышал.

Эм... Вы знаете стоимость "сходить по сокету" и стоимость "сходить по поинтеру"?.. Просто судя по всему - нет.

Тем более что в той задаче мемкеш не помог-бы.

Ну вернее помог, но это была-бы полумера

Ну это какой стороной повернуть

Какой не поверни.

Хехе, как скажешь ;)

Обосновать обратное сможете?

Шаредмемори, во-вторых, не кроссплатформенно. Во-первых, не  масштабируемо. В третьих не надёжно. Полностью реализована через page fault, copyin/copyout и контекст свитч так и так есть. Естественно, она немного быстрее, но перевешивает ли это все недостатки -- это уже зависит от задач, а это "Ну это какой стороной повернуть"

> не кроссплатформенно
Винда, Никсы, даже Фря... Издеваетесь? Как по мне не аргумент.
> не масштабируемо
Да, но прожить еще 5 лет в данной задачи оно-бы помогло. А уж на тачки раскатать процессы... Тоже не аргумент.
> не надёжно
Не надо говорить за конкретный кейс конкретно винды (насколько я помню). mmap и MapViewOfFile Позволяют не трогать page fault вооще.
> она немного быстрее
В данном случае она была-бы архитектурно проще и быстрее сокетов (насчет пайпов - не знаю. Надо смотреть. Вроде, пайпы сделаны на варианте mmap в ядре, но не берусь утверждать на 100%)

А что, теперь когда надо писать разный код под разные платформы уже называется  кроссплатформенностью?

5 лет? Хехе, это зависит от задачи. Я хз что там за задача.

Надёжность -- это в другую степь было.
Mmap позволяет не трогать pagefault, ты шутишь, да? Может там ещё волшебник биты передвигает, а протокол когерентности кешей нервно курит в сторонке? Мы ведь говорим об ммапе анонимной памяти, да?

Я хорошо знаю как устроена, например, фифофс. Это, конечно, не линекс, но суть не сильно меняется. И это точно не про ммап или что-то похожее.

И заметь, я перечислил только три недостатка, а их гораздо больше.

"Архитектурно проще и быстрее" -- это, кстати, показатель наколеночности проекта. Я видел много проектов и самыми успешными были те, у которых интегральное время на проектирование выше, чем те, у которых "хуяк хуяк, а можно и так, и в прод".

И ещё раз: я не говорю, что одно хуже другого. Я говорю, что использование одного или другого зависит от задачи. Мы ведь изначально обсуждали shm vs redis, так? :)

* если что, некоторые shm решения я видел в живых системах, которые обслуживают 1.6 млн запросов в секунду, имеют всего 16 цпу и лейтенси при этом в районе миллисекунд.

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

Опять-таки давайте отделять мух от котлет. Вы хотите пофлеймить redis vs shm? Не ко мне. Я до сих пор считаю редиску этаким мемкешом со свистоперделками.

Допустим, что знаю.
Но... "ближе к телу":
Как в чистом, породистом перле одни и те же данные делать общедоступными разным перл-процессам в памяти без обращения к "потусторонним" приблудам типа мемкешд?
Как это делать через "мемкешд" - знаю. Как в чисто перле - не знаю (Казань брал, Астрахань брал, квартиру Шпака - не брал)

в обход перла только

нельзя разделять перловые структуры данных