Здравствуйте, Critical Error, Вы писали:
CE>Ну насколько я понимаю, довольно трудно сделать скриптовый язык без GIL. Если не блокировать реальное параллельное выполнение, то можно необратимо повредить структуру объектов в памяти языка.
Ну это и в нескриптовых языках можно устроить. А можно избежать.

CE>Опять же с GC проблемы...
Ну вот их тоже быть не должно.

CE>Вообще питонисты когда им надо делать реально-параллельную работу спавнят еще один процесс интерпретатора и взаимодействуют друг с другом через какой-нибудь IPC.
CE>В общем чтобы не было проблем со структурой объектов в памяти надо смотреть в сторону языков с изолированными потоками. То есть там где объект будучи переданным другому потоку не разделяется, а полностью копируется. Там же должен быть свой менеджер кучи и свой GC на поток.
Нет, нужна именно шаред мемори, я просто забыл это в явном виде написать.

CE>Ну или в корне менять подход при работе с тредами. Можно посмотреть в сторону языков для БД. Например как оно сделано в PL/SQL?
Ненене, Дэвид Блейн.

CE>В Erlang разработчики все грозились сделать нативные треды. Вроде как деже сделали, но что у них получилось я не в курсе. Когда я последний раз работал с Erlang-ом, заметил интересную особенность при работе с драйвером ODBC. Тот самый драйвер отпочковывал некий процесс odbcserver.exe через который и проходили все блокирующие общения с базами данных. Вот такая вот нативная параллельность...
Тут

Автор:
Дата: 09.02.10

как раз обсуждались нативные потоки и асинхронность в эрланге. А odbcserver.exe вполне может относиться к деталям реализации odbc-драйвера и к эрланту относиться весьма опосредованно.