Python Shared Objects

Хоть бы одно слово для Ъ о том, что это такое.

Каноническое нинужна

Хоть бы одно слово для Ъ о том, что это такое

А, сорян, я чот уже туплю. Кароч, пока в питоне 30 лет не могут запилить нормальные потоки — я зашарил питоньи объекты между процессам. Если гора не идет к Магомету, то Магомет сам пойдет к горе.

С расшаренными объектами работа происходит примерно так же, как с обычными питоньими объектами, хотя спецификация стандартных объектов там еще реализована не полностью. В том числе шаренные объекты можно включать в состав обычных объектов или передавать аргументами функции. То есть, вроде как у тебя обычные питоноданные, а вроде как это всё тусит в разделяемой памяти и обновляется при изменении из другого процесса. А чтобы это изменение не развалило алгоритм — есть транзакции, которые позволяют атомарно читать-писать разделяемые данные. Внутри транзакции реализованы через множественные блокировки у отдельных объектов, и разруливаются они специальным алгоритмом, гарантирующим отсутствие дедлоков и голодания.

Короче говоря, эдакая объектная СУБД без персистентности с интерфейсом, который похож на обычный питоний код до степени слияния.

Каноническое нинужна

Вот, я подозреваю, что это реакция у 95% читающих. Ну, точнее, не читающих, потому что они не знают что не нужно и почему не нужно.

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

Важнее другое - на работу от непойми кого с одной репой на гитхабе нет никакого смысла смотреть. От работы продвинутого уровня от немойми кого с одной репой на гитхабе лучше держаться подальше

Во-о-от, это важное замечание. Да, я подозреваю, что эвристика мух работает таким образом и я этого не учел. Ну типа «ждем, пока Microsoft подарит нам новую порцию опенсорса». Все ж знают, что у GitHub две функции — хвастаться перед 20-летней HR-кой и качать оттуда опенсорс авторства гугла и фейсбука.

Only 32-bit Linux or Windows are supported

Таких зверей уже лет десять не встречал.

Таких зверей уже лет десять не встречал

Пф-ф-ф, сейчас любой линь умеет запускать 32 бита. Конечно, можно было со старта сделать только 64-бит версию, но там в любом раскладе трансляция адреса сложнее, чем в 32 бит, но 64-бит не запустится на 32 битных. Если вдруг такие есть. В принципе, поддерживать любую битность не так сложно, но там и без этого настолько много недоработок, что я уже не стал этой поддержкой заниматься.

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

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

если в питоне до сих пор нет тредов, то с питоном этим что-то не так.

С питоном все отлично, это с людьми которые 30 лет ищут там многопоточность и не находя чот не так.

Было б интересно, если б ты сделал возможность туда добавлять разные провайдеры вроде Redis, Memcache и т.п. Тогда можно было бы в вебе между инстансами одного отмасштабированного приложения реализовать обмен данными. Правда не уверен, что это сильно нужно. :)

С таким отношением к своему проекту неудивительно, что никто им не заинтересовался

Ты пробовал просто открыть сорцы и посмотреть СКОЛЬКО там кода? Ты докопался до копеечной хрени, которая для концепта не значит вообще ничего. Или ты уже собрался на этой версии 10 ГБ данных из прода катать?

https://github.com/colesbury/nogil/issues/8

Прочитай это сообщение и пойми глубину безысходности в которой ты оказался.

Там есть треды. Другое дело, что есть и GIL. А зачем тебе треды в питоне, кстати? Если решил сделать какое-то многопоточное молотилово на CPU, то питон в принципе для таких задач плохо подходит из-за низкой производительности.

А оно нужно? В том смысле, что ты какую-то реальную проблему проблему решил и сам используешь эту библиотеку?

Хабр на английском вызывает какой-то испанский стыд. СНГшная помоечка с апломбом.

А зачем тебе треды в питоне, кстати?

мне в питоне треды не нужны, я им не пользуюсь.

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

Так вообще-то питоновские треды позволяют это делать.

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

Блин, для школоты я мог бы описать попроще, но мне даром не нужна школота — мне нужны люди уровня Эрика Сноу, который нынче возглавляет разработку по PEP 554.

если в питоне до сих пор нет тредов, то с питоном этим что-то не так

Неочевидный факт: многопоточностью очень тяжело пользоваться. Еще менее очевидный факт: при помощи PSO многопоточностью пользоваться очень просто. К сожалению, накладные расходы слишком значительны для того, чтобы перенести модель разделяемой памяти в C/C++. Со скрипом оно может прокатить для каких-нибудь Go и шарпа.

При том, что чел, который недавно просто выкинул GIL из питона (просто выкинул, почему бы и нет) и выложил свое творение, словил кучу ответов.

Он не просто выкинул GIL. Ты хоть читал его предложение?

Было б интересно, если б ты сделал возможность туда добавлять разные провайдеры вроде Redis, Memcache и т.п. Тогда можно было бы в вебе между инстансами одного отмасштабированного приложения реализовать обмен данными. Правда не уверен, что это сильно нужно

Нифига не понял задумки, если честно. Куда «туда», что добавлять? Ну и я тоже не понял, зачем «это» «сильно нужно».

К сожалению, накладные расходы слишком значительны для того, чтобы перенести модель разделяемой памяти в C/C++

ну вот все пишут на плюсах разделяемые обьекты с RW мьютексом и хорошо живут(я например), а у тебя - «накладные расходы». да нет их там, кроме тех, что по логике положены.

Я просто знаю, что 32битный питон я устанавливать не буду в принципе. Поэтому твой проект пройдет мимо.

Он не просто выкинул GIL. Ты хоть читал его предложение?

Читал, конечно же. Он повесил синхронизацию на встроенные структуры данных. Ну типа без этого многопоточный питон без GIL завалится уже через десять миллисекунд многопоточности. Между прочим, это первое, что я попытался сделать. И я понял, что это совершенно бесполезно, потому что пласт софта под CPython, который не поддерживает и не будет поддерживать многопоточность, безграничен. Ты видел, что у него получилось написать на новом питоне? Вычисление чисел фибоначчи. Всё, больше оно ничего не может.

Ну ты пишешь «вроде как это всё тусит в разделяемой памяти». Соответственно в вебе это особо юзать не получится, т.к. процессы могут жить в разных контейнерах. Вот и спрашиваю, реально реализовать так, чтобы можно было выбирать, через что шарить объекты? Например, чтобы можно было шарить через Redis, Memcache или, быть может, как-то через веб-сокеты, таким образом, связав процессы в разных контейнерах, и реализовав обмен данными между ними. Мне кажется, область применимости тогда стала бы шире. Распределённый кэш получится.

Зато я смогу собрать и попробовать его проект, потому что

The proof-of-concept works best on Linux x86-64

Ну давай докопаемся до всего тобой написанного.

• 32 бита, серьезно? Ты 10 лет назад проект начинал?
• сложные структуры данных типа матриц numpy все равно не шарятся. Насколько я понял любая структура, где есть сишная часть не шарится.
• В коде не вычищены дебажные коменты https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L154
• https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L39

Строковая константа такой длины захардкоженая в условный оператор? Серьезно?

• https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L260 Обычный сишный блок дефайнов, ОК. Но кроме тебя никому не понятно как этим пользоваться. С камментами вообще жопа. Ты пишешь сложную либу для многопоточности, гда баги можно ловить десятилетиями. Прикинь как во всем этом разбираться другим людям.

• https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L377

Зачем дефайны констант в середине файла, не в начале или хэдере? Ты же даже в следующей за ними функции не пользуешься.

• https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L876 Почему i < 64? Это максимальное количество потоков, ядер, размер страницы, что это вообще такое? Это нужно в константу.

• https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L990 Вот зачатки хорошо документированной функции для библиотеки такого уровня. Но только начало.

• https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L1445 Опять переменные в середине файла и без описания. Еще и статические, что подразумевает, что их будут дергать хрен знает откуда.

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

Хабр на английском вызывает какой-то испанский стыд. СНГшная помоечка с апломбом.

Как боженька сказанул! Ладно бы медиум, но англохабр, это потеха для людей знающих английский настолько плохо, что вынуждены еще сидеть на хабре.

ну вот все пишут на плюсах разделяемые обьекты с RW мьютексом и хорошо живут(я например)

Да, всё течет, всё дедлочится. Причем, если история про повреждением памяти для Rust меньше актуальна, то с дедлоками он не помогает вообще никак. Хотя, на самом деле Rust не решает даже проблем с памятью для сложных структур.

Проблема в чем: если ты хочешь железобетонную гарантию надежности, то ты лочишь родительскую структуру, увеличиваешь счетчик по ссылке из родительской структуры, разлочиваешь родительскую структуру, пользуешься объектом. И так для каждого перехода по ссылке. Как ты понимаешь, это дичайший трафик по кэшу. Если ты это дело пытаешься оптимизировать, то внезапно лишаешься всех гарантий раста. Нельзя не брать блокировку на родительский объект, потому что кто-то очистит ссылку и ты увеличишь счетчик ссылок с торжественным сегфолтом.

Как правило, вся эта проблема решается путем минимизации работы с разделяемой памятью. А еще лучше — устранением многопоточности.

Соответственно в вебе это особо юзать не получится, т.к. процессы могут жить в разных контейнерах. Вот и спрашиваю, реально реализовать так, чтобы можно было выбирать, через что шарить объекты? Например, чтобы можно было шарить через Redis, Memcache или, быть может, как-то через веб-сокеты

А, ты про это. Так я ж собрался убивать микросервисы. Весь смысл микросервисов как бы был в том, что у питона нету многозадачности, и потому ее прикостыливают сбоку через внешние сервисы. С PSO ранее острая необходимость в конкретно Redis и Memcached становится уже сомнительной. Соответственно, с PSO подразумевается, что у тебя есть тупо один единственный контейнер, в котором работает и самокоординируется семейство воркеров питона.

С PSO ранее острая необходимость в конкретно Redis и Memcached становится уже сомнительной.

А не ты ли на хабре писал, что твоя библиотека таки не решает проблему шаринга сложных структур, и как вариант предлагал ZeroMQ? Ну типа красиво сманеврировал. Тут пишешь, что редиска не нужна, ведь есть PSO. А на хабре пишешь, что PSO можно заменить ZeroMQ.

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

При том, что чел, который недавно просто выкинул GIL из питона (просто выкинул, почему бы и нет) и выложил свое творение,

https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/

Сходи к ребятам вот сюда и спроси чем помочь. далее тред не вижу смысла продолжать ибо плачь ярославны.

32 бита, серьезно? Ты 10 лет назад проект начинал?

Справедливое замечание. Я не придавал этому значения, но, судя по всему, это серьезное препятствие для многих.

сложные структуры данных типа матриц numpy все равно не шарятся. Насколько я понял любая структура, где есть сишная часть не шарится

NumPy шарится, как я отвечал на хабре, но нужна дополнительная разработка. У него и у PyTorch из коробки есть возможность работать через разделяемую память. Другое дело, что из коробки там нет атомарных операций — с ними-то и нужно что-то придумать.

Строковая константа такой длины захардкоженая в условный оператор? Серьезно?

Конкретно эта функция (_make_filename) — копипаста из стандартной либы питона. По этой причине есть довольно большой шанс, что она не содержит багов.

С камментами вообще жопа. Ты пишешь сложную либу для многопоточности, гда баги можно ловить десятилетиями. Прикинь как во всем этом разбираться другим людям

Многопоточная часть (например, take_write_lock) там утыкана комментами с ног до головы. Ее не так много — большая часть реализации самих контейнеров работает под блокировками.

Вот что более актуально (и что отмечено в комментах, как ни странно) — это что комменты в take_write_lock частично устарели и единственный способ по-настоящему понять, как оно работает — это таки прочитать код. Причем, 2/3 этого кода я планирую почистить, потому что задуманный мной изначально алгоритм точных ожиданий оказался очень сложным при том скромном эффекте, который он дает. На бесконечных циклах с нарастающей паузой через _mm_pause + yield + usleep производительность плюс-минус такая же, а читать и поддерживать код будет проще.

Зачем дефайны констант в середине файла, не в начале или хэдере? Ты же даже в следующей за ними функции не пользуешься

И это моя ошибка, потому что вообще-то именно они в следующей функции и должны были возвращаться. Это внутренние константы которые актуальны только для shm_thread_start_compare и ее пользователей. Что им ловить в начале файла? Кодер откроет файл на начале, посмотрит на них, «и че мне с ними делать? А где комменты, для чего они нужны и к чему относятся?». А тут, как ни странно, комменты и не нужны. А код я подправлю.

Почему i < 64? Это максимальное количество потоков, ядер, размер страницы, что это вообще такое? Это нужно в константу

Да, это sizeof(ShmReaderBitmap)*8, и это нужно в константу.

https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6...
Вот зачатки хорошо документированной функции для библиотеки такого уровня. Но только начало

А, ну да, ты сам дошел до take_write_lock.

https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6... Опять переменные в середине файла и без описания. Еще и статические, что подразумевает, что их будут дергать хрен знает откуда

Логирующий флаг. Простой поиск показывает, что ее не будут дергать ниоткуда — он просто устанавливается в одном месте, чтобы один раз тригернуть fprintf(stderr, ...). Собственно, она прямо там рядом и лежит.

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

Ну-у-у, там 14 тысяч строк, ты на одной десятой сдался уже просто просматривать. А прикинь, сколько это было писать и отлаживать? А оно ж работает, падла такая, и с весьма неплохой производительностью.

Пока что из всех замечаний по коду 100% относятся к стилю, 0% к логике. Ты пробовал когда-нибудь писать прототип, 50% которого ты с очень большой вероятностью полностью перепишешь через пару месяцев? Ты будешь его аккуратно комментировать, вычищать отладочный код сразу как только он тебе не нужен, ну и просто беспощадно чистить весь лишний код (ты же знаешь, что он тебе не пригодится)? Ты же понимаешь, что я мог бы сесть и начать маникюрить код, но это привело к тому, что релизнул бы я его на несколько месяцев позже? На несколько месяцев — потому что у меня, вообще-то, есть работа, и есть хобби, и отдохнуть бы тоже надо.

Да, всё течет, всё дедлочится. Причем, если история про повреждением памяти для Rust меньше актуальна, то с дедлоками он не помогает вообще никак. Хотя, на самом деле Rust не решает даже проблем с памятью для сложных структур.

причем тут раст, какие-то «повреждения памяти»…мне на раст вообще положить. я про плюсы говорю.

Проблема в чем: если ты хочешь железобетонную гарантию надежности, то ты лочишь родительскую структуру, увеличиваешь счетчик по ссылке из родительской структуры, разлочиваешь родительскую структуру, пользуешься объектом.

вы только что открыли реализацию канонического рекурсивного мьютекса. вот именно тред монопольно инкрементирует счетчик в нем… и пользуется «обьектом»…и пока он не уменьшит его до нуля, другой тред будет стоять в ожидании на этом мьютексе. вы там чота изобретаете в синхронизации, что давно изобретено.

Как боженька сказанул! Ладно бы медиум, но англохабр, это потеха для людей знающих английский настолько плохо, что вынуждены еще сидеть на хабре

Я ненавижу медиум за его неюзабельный интерфейс. Из англоязычных хуже знаю только реддит — там вообще дефолтный редактор делает винегрет из текста и даже удаляет сообщение целиком. Просто так, нравится ему это делать. В принципе, я мог бы выложить это куда угодно. Как вариант — в своем личном бложике. Которого у меня не текущий момент нету. А теперь представь, что через энное время я забью на свой бложик и перестану его хостить. Два с половиной человека поднимут вой «как же так, где моя статья?».

Поскольку я не сишник я вообще плохо понимаю, что там написано. Но просто *формальных* способов послать тебя нафиг дофига. Я хочу донести до тебя простую мысль - ты никто и звать тебя никак, и этого часто достаточно для того чтобы послать весь твой код нафиг. А у тебя в коде куча проблем, до который можно докопаться, разгромив его. А речь идет за питон, где годами многострочные лямбды не могут пропихнуть или выпиливание GIL, потому что иди на хрен вот почему. Я не знаю чего ты хочешь добиться своим проектом, но пока это очень далеко от состояния «это станет пепом». Если ты просто привлекаешь внимание людей к наболевшей проблеме питона, ну ок. Но ты уверен что ты первый такой?

вы только что открыли реализацию канонического рекурсивного мьютекса. вот именно тред монопольно инкрементирует счетчик в нем… и пользуется «обьектом»…и пока он не уменьшит его до нуля, другой тред будет стоять в ожидании на этом мьютексе. вы там чота изобретаете в синхронизации, что давно изобретено

Не, ты не понял: счетчик ссылок — это счетчик ссылок shared_ptr, который используется для высвобождения и повторного использования памяти. Ты же не будешь руками решать, какой объект высвобождать сейчас, а какой — пока что отложить и подождать? Или будешь?

Ну если звёзд насобирает штук 200 хотя бы - может быть, проект будет восприниматься иначе

А не ты ли на хабре писал, что твоя библиотека таки не решает проблему шаринга сложных структур, и как вариант предлагал ZeroMQ?

Не я. Тогда возникает вопрос: а кто писал? Кто занимался на хабре решением подобной задачи?

Моя либа как раз именно решает проблему шаринга сложных структур — весь ее смысл в этом.

Еще я писал про ZeroMQ на реддите, но там было про другое — чел предложил отправку сообщений, на что я резонно ответил «тебе в ZeroMQ или что-то подобное».

https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L853

Вообще хз что это, но если у тебя и решение что освобождать принимается конструкциями уровня (random_flinch && rand() % 128 == 3), то осовобождать руками выглядит как не самая плохая затея.

Опять же, строки 853, 904, 1079, 1122, 1149 - это жуткий неочевидный хардкод.

Случайно нашел: https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6439978883248b165/src/shm_base.c#L2128 else what?

Вот это сообщение https://habr.com/ru/post/585320/#comment_23629316 :

NumPy-массив, как я писал в статье, можно поместить в разделяемую память ( и модель PyTorch тоже), но дальше возникает проблема - что с ними делать? Передавать между процессами ID сегмента? Это можно сделать любым инструментом, будь то multiprocessing или ZeroMQ, там накладные расходы от передачи строки ничтожны по сравнению с обработкой с самих данных.

Ты уже определись, нужон ли твой PSO, ведь один хрен с ним либы полноценно не работают, и проще юзать ZeroMQ, или у тебя все из коробки и прозрачно?

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

А речь идет за питон, где годами многострочные лямбды не могут пропихнуть или выпиливание GIL, потому что иди на хрен вот почему

Метко выразил суть модели разработки питона.

Я не знаю чего ты хочешь добиться своим проектом, но пока это очень далеко от состояния «это станет пепом»

А этому и не нужно быть пепом, оно прекрасно себя чувствует сбоку. Максимум — это синтаксический сахар пропихнуть пепом.

Если ты просто привлекаешь внимание людей к наболевшей проблеме питона, ну ок. Но ты уверен что ты первый такой?

Все-таки самая главная моя цель — это показать, что в многопоточности/многозадачности/распределенности я соображаю лучше, чем 99% рынка труда. «Раздача халявы» вполне может служить хорошим помощником в этой задаче. Буду благодарен за подсказки более коротких путей успеха. Сразу преждупрежу: я не буду ковырять говно вилкой за еду, мне больше нравится забесплатно заниматься тем, к чему располагает душа.

Имхо, если ты все равно сделал свою хрень не подменяющую стандартные list/tuple, что там еще в питоне, надо было брать готовую библиотеку. Тот же ZeroMQ, или какую-то MT-ready сишную библиотеку для реализации структур хэштаблица, массив. И делать вокруг него тонкий слой обертки. У тебя, я так понимаю, все равно нет нативных питоновых объектов. Все лежит в неймспейсе PSO. Т.е. ты взял самую сложную часть, криво(скорее всего, я не спец) ее реализовал, и сделал для нее обертку в виде ВНЕШНИХ объектов. Ну типа тех тех же матриц NumPy.

Бросай это дело нахрен. Делай редкие причесывающие коммиты. 99% рынка собеседователей не поймет как ты обосрался. Делай параллельно красивую обертку для зрелой оттестированой сишнйо либы, которая нормально может в многопоточность и ложиться на структуры данных питона.

Ты главное пойми, я не сишник, а вот настоящий сишник тебя раз**т как козла, даже не касаясь писи оного. Тут надо вдумчивее подходить к делу.

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

Какой статический анализатор/линтер ты предлагаешь? Если прогнать по gcc -Wall -Wshadow -Wconversion, то, в принципе, можно получить 70 варнингов, в основном по знакам интов, поскольку у меня дофига битовых операций над -1. Особенно вот эта хрень мерзкая:

src/shm_types.h:351:20: warning: signed conversion from ‘unsigned int’ to ‘int’ changes value from ‘4294967295’ to ‘-1’ [-Wsign-conversion]
 # define EMPTY_SHM ((__ShmPointer)-1)

Ты главное пойми, я не сишник, а вот настоящий сишник тебя раз**т как козла, даже не касаясь писи оного. Тут надо вдумчивее подходить к делу

Ой, я бы с радостью пообщался бы с таким.

Вообще хз что это, но если у тебя и решение что освобождать принимается конструкциями уровня (random_flinch && rand() % 128 == 3), то осовобождать руками выглядит как не самая плохая затея

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

Опять же, строки 853, 904, 1079, 1122, 1149 - это жуткий неочевидный хардкод

Ну вообще да, нужно грамотно реализовать подстройку делителя для лучшей отладочки, но, увы, я этого еще не сделал, потому оформлять это не имеет особого смысла. Особенно учитывая, что это чисто отладочная фича.

А что неочевидно? Что при random_flinch = true эта конструкция 3 раза из 128 кинет выполнение в эту ветку? На мой взгляд более чем очевидно.

Случайно нашел: https://github.com/byko3y/python-shared-objects/blob/3e7ead79f8118caf20dbb0a6... else what?

Ну можно туда shmassert(false) воткнуть. Я подозреваю, что он там уже был, но в какой-то момент я его потер оттудава. Я исповедую культ инициализации переменных, передаваемые по ссылке, потому значение transaction_mode и transaction_lock_mode не будет неопределенным, а idx у нас инициализирован.

NumPy-массив, как я писал в статье, можно поместить в разделяемую память ( и модель PyTorch тоже), но дальше возникает проблема - что с ними делать? Передавать между процессами ID сегмента? Это можно сделать любым инструментом, будь то multiprocessing или ZeroMQ, там накладные расходы от передачи строки ничтожны по сравнению с обработкой с самих данных.

Ты уже определись, нужон ли твой PSO, ведь один хрен с ним либы полноценно не работают, и проще юзать ZeroMQ, или у тебя все из коробки и прозрачно?

А, ну так он предлагал не сложные данные, а вполне себе одиночные объекты NumPy и PyTorch. Разделяемая память в эти либы уже встроена, и если нужно передать просто ссылку на один объект — это можно сделать чем угодно, у меня не библиотека передачи сообщений, у меня библиотека транзакционного доступа к разделяемой памяти.