Разыскивается, возможно, немного странная вещь: имплементация любого языка с поддержкой нативных потоков. Пожелания:
— Собственно, нативные потоки.
— Открытые исходники, должны допускать внесение изменений и работать в windows (хуже) или linux (лучше).
— Не слишком сложный код реализации, чтобы в нем реально было разобраться без каких-то специфичных познаний. Было бы здорово услышать комментарий в духе "искал (делал) X, потратил N времени".
— Желательно — интерпретатор или компилятор в байт-код (дальнейшая судьба байткода безразлична).
— Императивная направленность (а-ля lua, python). Функциональщина и иммутабельность — скорее минус.
— Легкие потоки, корутины, csp, макросы, строгая типизация, монады-хренады и прочая муть допустимы, если не мешаются под ногами.
— Хотелось бы, чтобы не слишком тормозная. По идее, что-то на уровне lua сойдет.
В итоге разыскиваются lua или python с нативными потоками (поскольку я не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, вдруг кто чего подскажет). Цель — внесение некоторых изменений в имплементацию.
Здравствуйте, Mr.Cat, Вы писали:
MC>В итоге разыскиваются lua или python с нативными потоками (поскольку я не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, вдруг кто чего подскажет). Цель — внесение некоторых изменений в имплементацию.
Ну так в Python модуль threading как раз реализует нативные потоки. Только в Python есть GIL, который не позволяет выполнять одновременно инструкции самого языка. Хотя можно в своем расширении на C освободить GIL, но тогда уже нельзя будет дергать Python API.
Здравствуйте, Critical Error, Вы писали: CE>Ну так в Python модуль threading как раз реализует нативные потоки. Только в Python есть GIL, который не позволяет выполнять одновременно инструкции самого языка.
Вот как раз GIL и хотелось бы отправить в печку. Чтобы в разных нативных потоках выполнялся код на самом языке.
Здравствуйте, Mr.Cat, Вы писали:
MC>В итоге разыскиваются lua или python с нативными потоками (поскольку я не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, вдруг кто чего подскажет). Цель — внесение некоторых изменений в имплементацию.
Здравствуйте, Mr.Cat, Вы писали:
MC>В итоге разыскиваются lua или python с нативными потоками (поскольку я не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, вдруг кто чего подскажет). Цель — внесение некоторых изменений в имплементацию.
Здравствуйте, Mr.Cat, Вы писали:
MC>Вот как раз GIL и хотелось бы отправить в печку. Чтобы в разных нативных потоках выполнялся код на самом языке.
Ну насколько я понимаю, довольно трудно сделать скриптовый язык без GIL. Если не блокировать реальное параллельное выполнение, то можно необратимо повредить структуру объектов в памяти языка. Обычно это ведет к падению. Когда-то я писал расширение на C++ для Python. Тогда я еще не знал про GIL. Так вот эти мои эксперименты заканчивались эпическими крашами всей системы. Опять же с GC проблемы... Вообще питонисты когда им надо делать реально-параллельную работу спавнят еще один процесс интерпретатора и взаимодействуют друг с другом через какой-нибудь IPC.
В общем чтобы не было проблем со структурой объектов в памяти надо смотреть в сторону языков с изолированными потоками. То есть там где объект будучи переданным другому потоку не разделяется, а полностью копируется. Там же должен быть свой менеджер кучи и свой GC на поток. Может еще быть какое-нибудь встроенное средство для обмена сообщениями. Честно сказать я такого языка не знаю
Ну или в корне менять подход при работе с тредами. Можно посмотреть в сторону языков для БД. Например как оно сделано в PL/SQL?
В Erlang разработчики все грозились сделать нативные треды. Вроде как деже сделали, но что у них получилось я не в курсе. Когда я последний раз работал с Erlang-ом, заметил интересную особенность при работе с драйвером ODBC. Тот самый драйвер отпочковывал некий процесс odbcserver.exe через который и проходили все блокирующие общения с базами данных. Вот такая вот нативная параллельность...
Здравствуйте, Mr.Cat, Вы писали:
MC>В итоге разыскиваются lua или python с нативными потоками (поскольку я не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, вдруг кто чего подскажет). Цель — внесение некоторых изменений в имплементацию.
А какие проблемы вообще запустить VM в native thread?
Или нужны threading примитивы встроенные в язык?
Здравствуйте, Mr.Cat, Вы писали:
MC>В итоге разыскиваются lua или python с нативными потоками (поскольку я не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, вдруг кто чего подскажет). Цель — внесение некоторых изменений в имплементацию.
Ну, TCL например. Насколько я знаю, там у него по интерпретатору на поток, поэтому без глобального лока.
Здравствуйте, c-smile, Вы писали:
CS>А какие проблемы вообще запустить VM в native thread? CS>Или нужны threading примитивы встроенные в язык?
CS>Если второе то язык имени меня такое имеет: http://c-smile.sourceforge.net/
CS>Вот например: CS>http://c-smile.sourceforge.net/samples/threads.htm
CS>Примитивы thread (объект) и synchronized(mutex) {}
А можно поподробнее об многопоточности в Вашем скриптовом языке?
Как например у Вас реализована работа с GC. Вот предположим объект передается в другой тред и получаются 2 ссылки из разных потоков? Или делается полное копирование объекта?
Или вот если объект видят одновременно два треда, то каким образом удается его не порушить? Блокируется каждый объект в отдельности? Или синхронизацию нужно делать также как и в С++, вручную?
On 21/02/2010 00:54, Mr.Cat wrote:
> В итоге разыскиваются lua или python с нативными потоками (поскольку я > не знаю, как в них обстоят дела с сабжем — решил поинтересоваться тут, > вдруг кто чего подскажет). Цель — внесение некоторых изменений в > имплементацию.
А чем плох JVM? В принципе даже сама java в каком-то смысле поддаётся скриптованию. А можно и какой-нибудь groovy.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Critical Error, Вы писали: CE>Ну насколько я понимаю, довольно трудно сделать скриптовый язык без GIL. Если не блокировать реальное параллельное выполнение, то можно необратимо повредить структуру объектов в памяти языка.
Ну это и в нескриптовых языках можно устроить. А можно избежать.
CE>Опять же с GC проблемы...
Ну вот их тоже быть не должно.
CE>Вообще питонисты когда им надо делать реально-параллельную работу спавнят еще один процесс интерпретатора и взаимодействуют друг с другом через какой-нибудь IPC. CE>В общем чтобы не было проблем со структурой объектов в памяти надо смотреть в сторону языков с изолированными потоками. То есть там где объект будучи переданным другому потоку не разделяется, а полностью копируется. Там же должен быть свой менеджер кучи и свой GC на поток.
Нет, нужна именно шаред мемори, я просто забыл это в явном виде написать.
CE>Ну или в корне менять подход при работе с тредами. Можно посмотреть в сторону языков для БД. Например как оно сделано в PL/SQL?
Ненене, Дэвид Блейн.
CE>В Erlang разработчики все грозились сделать нативные треды. Вроде как деже сделали, но что у них получилось я не в курсе. Когда я последний раз работал с Erlang-ом, заметил интересную особенность при работе с драйвером ODBC. Тот самый драйвер отпочковывал некий процесс odbcserver.exe через который и проходили все блокирующие общения с базами данных. Вот такая вот нативная параллельность... Тут
как раз обсуждались нативные потоки и асинхронность в эрланге. А odbcserver.exe вполне может относиться к деталям реализации odbc-драйвера и к эрланту относиться весьма опосредованно.
Здравствуйте, c-smile, Вы писали: CS>А какие проблемы вообще запустить VM в native thread? CS>Или нужны threading примитивы встроенные в язык?
Вроде того. А также шаред мемори между потоками.
CS>Если второе то язык имени меня такое имеет: http://c-smile.sourceforge.net/ CS>http://c-smile.sourceforge.net/samples/threads.htm CS>Примитивы thread (объект) и synchronized(mutex) {}
Хм... вспоминая темы про htmlayout, там внурях хардкорный C++
Здравствуйте, LuciferSaratov, Вы писали: LS>Ну, TCL например. Насколько я знаю, там у него по интерпретатору на поток, поэтому без глобального лока.
А память между потоками разделяемая?
Здравствуйте, ., Вы писали: .>А чем плох JVM?
Да вроде ничем не плох. По идее, нечто компилироемое в jvm или clr как раз подошло бы, главное чтобы в коде нечта можно было разобраться.
Здравствуйте, Mr.Cat, Вы писали:
MC>Нет, нужна именно шаред мемори, я просто забыл это в явном виде написать.
Ну, просто очень редко встречаются алгоритмы, где нельзя обойтись без Shared Memory... И такие алгоритмы обычно пишутся на чем-то более низкоуровневом... Эта фича действительно вам так нужна, или просто привычка?
Здравствуйте, Critical Error, Вы писали: CE>Ну, просто очень редко встречаются алгоритмы, где нельзя обойтись без Shared Memory... И такие алгоритмы обычно пишутся на чем-то более низкоуровневом... Эта фича действительно вам так нужна, или просто привычка?
Фича нужна, без нее никак.
