История изменений

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

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

Весь смысл клонирования процессов без CoW (при котором и создаются потоки) - в расшаривании данных, потому что обращение к памяти - весьма медленная операция.

Perl'овые потоки - такой же кривой механизм, как и потоки Python, просто суть кривости в другом. Ну да, интерпрератор сам себя копирует в каждый поток, чтобы там состояние интерпретатора было уникальным для потока, но при использовании пулов это грозит только нерациональным расходом памяти. Зато в Python есть прекрасная «блокировка интерпретатора» (https://ru.wikipedia.org/wiki/Global_Interpreter_Lock), которая делает параллельность непараллельной, причём не только для потоков, которым нужны одни и те же данные, но и для вообще всех потоков (из соображений «как бы чего не вышло»).

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

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

Весь смысл клонирования процессов без CoW (при котором и создаются потоки) - в расшаривании данных, потому что обращение к памяти - весьма медленная операция.

Perl'овые потоки - такой же кривой механизм, как и потоки Python, просто суть кривости в другом. Ну да, интерпрератор сам себя копирует в каждый поток, чтобы там состояние интерпретатора было уникальным для потока, но при использовании пулов это грозит только нерациональным расходом памяти. Зато в Python есть прекрасная «блокировка интерпретатора» (https://ru.wikipedia.org/wiki/Global_Interpreter_Lock), которая делает параллельность непараллельной, причём не только для потоков, которым нужны одни и те же данные, но и для вообще всех потоков (из соображений «как бы чего не вышло»).

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

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

Весь смысл клонирования процессов без CoW (при котором и создаются потоки) - в расшаривании данных, потому что обращение к памяти - весьма медленная операция.

Perl'овые потоки - такой же кривой механизм, как и потоки Python, просто суть кривости в другом. Ну да, интерпрератор сам себя копирует в каждый поток, чтобы там состояние интерпретатора было уникальным для потока, но при использовании пулов это грозит только нерациональным расходом памяти. Зато в Python есть прекрасная «блокировка интерпретатора» (https://ru.wikipedia.org/wiki/Global_Interpreter_Lock), которая делает параллельность непараллельной, причём не только для потоков, которым нужны одни и те же данные, но и для вообще всех потоков (из соображений «как бы чего не вышло»).