The Caml run-time system is not reentrant: at any time, at most one thread
can be executing Caml code or C code that uses the Caml run-time system.
Technically, this is enforced by a "master lock" that any thread must hold
while executing such code.
это ставит крест на очень многих возможных применениях
Да, с параллелизмом на уровне потоков там туго. Сборщик мусора, работающий в многопоточной программе, намного сложнее и тормознее, поэтому авторы сознательно оставили его однопоточным, а параллелить предлагают на уровне обменивающихся сообщениями процессов, считая shared memory parallelism вообще тупиковой ветвью. Есть проект многопоточного GC для окамла — oc4mc, он вроде работает, но действительно заметно медленнее.
Эта ситуация с потоками — одна из причин, почему я еще не везде отказался от С++ в пользу окамла.
DM>Да, с параллелизмом на уровне потоков там туго. Сборщик мусора, работающий в многопоточной программе, намного сложнее и тормознее, поэтому авторы сознательно оставили его однопоточным, а параллелить предлагают на уровне обменивающихся сообщениями процессов, считая shared memory parallelism вообще тупиковой ветвью. Есть проект многопоточного GC для окамла — oc4mc, он вроде работает, но действительно заметно медленнее.
DM>Эта ситуация с потоками — одна из причин, почему я еще не везде отказался от С++ в пользу окамла.
Я правильно понял, что в окамле точно такой же GIL как в питоне?
Здравствуйте, D. Mon, Вы писали:
DM>Да, с параллелизмом на уровне потоков там туго. Сборщик мусора, работающий в многопоточной программе, намного сложнее и тормознее, поэтому авторы сознательно оставили его однопоточным, а параллелить предлагают на уровне обменивающихся сообщениями процессов, считая shared memory parallelism вообще тупиковой ветвью. Есть проект многопоточного GC для окамла — oc4mc, он вроде работает, но действительно заметно медленнее.
DM>Эта ситуация с потоками — одна из причин, почему я еще не везде отказался от С++ в пользу окамла.
Я давно к нему (OCaml-у) присматривался, но так и не решился его использовать. Как я понял, у тебя богатый опыт использования OCaml, если не трудно, не ответишь на пару вопросов?
— ты пишешь все приложение целиком ан OCaml, или только какую-то часть? Если часть, как организуешь взаимодействие?
— компилятор умеет генерировать нативный код для ARM процессоров? можно ли использовать OCaml на мобильных платформах?
— как обстоят дела с поддержкой 64 битных систем?
Здравствуйте, Temoto, Вы писали:
T>Я правильно понял, что в окамле точно такой же GIL как в питоне?
Я не знаю подробностей про питоний, но в целом похоже. Можно иметь много окамловых потоков, но они будут работать не одновременно, а как на одноядерной машине. Из окамла можно вызвать код на Си, в котором использовать много потоков. Если они не лезут в кучу окамла, то они могут работать параллельно окамловскому коду.
T>>Я правильно понял, что в окамле точно такой же GIL как в питоне?
DM>Я не знаю подробностей про питоний, но в целом похоже. Можно иметь много окамловых потоков, но они будут работать не одновременно, а как на одноядерной машине. Из окамла можно вызвать код на Си, в котором использовать много потоков. Если они не лезут в кучу окамла, то они могут работать параллельно окамловскому коду.
Точно такой же.
Спасибо, вы открыли мне глаза. Кошмар, ужас, разочарование.
У меня опыт сравнительно долгий, но не шибко богатый (в плане платформ и библиотек).
KP>- ты пишешь все приложение целиком ан OCaml, или только какую-то часть? Если часть, как организуешь взаимодействие?
Целиком, кое-какие мелочи иногда дописываются на С и линкуются.
KP>- компилятор умеет генерировать нативный код для ARM процессоров? можно ли использовать OCaml на мобильных платформах?
На линуксах и маках — отлично. Кодогенератор для 64 бит лучше 32-битного, и нет таких дурацких ограничений на размер массивов и строк. Для винды 64-битная версия вроде как есть, но на официальном сайте нет бинарников, а самостоятельно собрать редкая птица сможет. Я пользуюсь 32-битной.
А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
Здравствуйте, kaa.python, Вы писали:
KP>А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
Это надо, чтобы у каждого была своя куча и те части рантайма, которые сейчас не reentrant. Непросто это. Но можете попробовать.
Re[5]: OCaml - язык общего назначения?
От:
Аноним
Дата:
18.08.11 20:51
Оценка:
Здравствуйте, kaa.python, Вы писали:
KP>А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
а смысл? тогда окамловые вещи будут полностью изолированы друг от друга, и не смогут коммуницировать кроме как через С-код. даже если такое сделать, то будет очень много проблем склеивания
KP>>А можно зайти с другой стороны. Например иметь несколько Сишных потока из которых обращаться к различным инстансам Окамла, но в рамках одного процесса?
А>а смысл?
Смысл в том, что однопоточные приложения, на данный момент, практически бесполезны. Макимум какая-то консольная утилита, и то не факт.
А> тогда окамловые вещи будут полностью изолированы друг от друга, и не смогут коммуницировать кроме как через С-код. даже если такое сделать, то будет очень много проблем склеивания
Изолированность не проблема. Любая задача довольно просто может быть разбита на подзадачи, которые уже и будут выполняться паралельно. А вот что делать с монолитным приложением, которое не в состоянии выполнить задачу в отдельном потоке. Практически бесполезно это
Здравствуйте, kaa.python, Вы писали:
KP>Изолированность не проблема.
Тогда можно разделить на несколько параллельных процессов, что и предлагают авторы языка. В Хроме вон так сделали и очень гордятся результатом.
KP> Любая задача довольно просто может быть разбита на подзадачи, которые уже и будут выполняться паралельно. А вот что делать с монолитным приложением, которое не в состоянии выполнить задачу в отдельном потоке. Практически бесполезно это
Задачу-то можно выполнить в отдельном потоке, просто не так быстро. Но если задача не числомолотилка, а ввод-вывод, то разница с "настоящим" параллельным потоком вряд ли будет заметна при правильном подходе.
Для однопоточных программ тоже немало применений есть. Например, я делал на окамле интерактивный анализатор логов с веб-интерфейсом. Не представляю, где бы мне там пригодились параллельные потоки (с диска читать лучше последовательно, а пользователь один, и много запросов сразу не посылает). Еще делал компилятор, он и без потоков очень быстрый получился.
Здравствуйте, D. Mon, Вы писали:
DM>Здравствуйте, kaa.python, Вы писали:
KP>>Изолированность не проблема.
DM>Тогда можно разделить на несколько параллельных процессов, что и предлагают авторы языка. В Хроме вон так сделали и очень гордятся результатом.
В Хроме, кроме того, каждый процесс запускает потоки для различных фоновых операций. Куда ж без этого?
DM>Задачу-то можно выполнить в отдельном потоке, просто не так быстро. Но если задача не числомолотилка, а ввод-вывод, то разница с "настоящим" параллельным потоком вряд ли будет заметна при правильном подходе.
Сейчас идет тенденция к увеличению количества процессоров. Зачем же целенаправленно вводить какие-то ограничения и усложнять самому себе жизнь?
DM>Для однопоточных программ тоже немало применений есть. Например, я делал на окамле интерактивный анализатор логов с веб-интерфейсом. Не представляю, где бы мне там пригодились параллельные потоки (с диска читать лучше последовательно, а пользователь один, и много запросов сразу не посылает). Еще делал компилятор, он и без потоков очень быстрый получился.
Там бы они пригодились для раздельного чтения и анализа. Пользователей может быть больше чем 1. Хотя в приведенном тобой случае одного потока достаточно, согласен.
Т.е. да, для рядя задач одного потока хватает. Просто для моих задач наличие возможности запустить фоновую операцию критично. На столько критично.
Re[9]: OCaml - язык общего назначения?
От:
Аноним
Дата:
20.08.11 07:21
Оценка:
Здравствуйте, kaa.python, Вы писали:
KP>Т.е. да, для рядя задач одного потока хватает. Просто для моих задач наличие возможности запустить фоновую операцию критично. На столько критично.
пока я вижу только один выход — если ест что-то ресурсоемкое (или просто длинное) фоновое, то можно запускать в отдельно окамловском потоке, который будет дергать С-callback, в котором будет сначала освобождаться gil, а только потом выполняться та самая ресурсоемкая задача.
честно говоря, не ожидал — тут столько лет разговоры были о окамле, как о полноценной замене С++, а когда руки дошли повозиться — получите, распишитесь
Re[10]: OCaml - язык общего назначения?
От:
Аноним
Дата:
22.08.11 10:50
Оценка:
Здравствуйте, Аноним, Вы писали:
А>честно говоря, не ожидал — тут столько лет разговоры были о окамле, как о полноценной замене С++, а когда руки дошли повозиться — получите, распишитесь
А можно поинтересоваться — на кой вообще нужна shared memory concurrency? Проблем мало, хочется по-комсомольски, стоя в гамаке?
Здравствуйте, Аноним, Вы писали:
А> А можно поинтересоваться — на кой вообще нужна shared memory concurrency? Проблем мало, хочется по-комсомольски, стоя в гамаке?
Мне вот нужна, чтобы при обработке видео можно было разделить картинку на части и обрабатывать их параллельно. Причем для каждого куска нужны исходные данные не только из него самого, но и из других. Как прикажете это делать без shared memory?
KP>Смысл в том, что однопоточные приложения, на данный момент, практически бесполезны. Макимум какая-то консольная утилита, и то не факт.
На OCaml можно писать многопоточные приложения, но при этом фактически будет использоваться только одно ядро процессора. С потоками никаких
проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.
А>> тогда окамловые вещи будут полностью изолированы друг от друга, и не смогут коммуницировать кроме как через С-код. даже если такое сделать, то будет очень много проблем склеивания
KP>Изолированность не проблема. Любая задача довольно просто может быть разбита на подзадачи, которые уже и будут выполняться паралельно. А вот что делать с монолитным приложением, которое не в состоянии выполнить задачу в отдельном потоке. Практически бесполезно это
Если в потоках нет тяжелых вычислений то никаких проблем, иначе получим тормоза (по сравнению скажем с аналогом на C++) на многоядерных машинах.
Здравствуйте, kaa.python, Вы писали:
KP>В Хроме, кроме того, каждый процесс запускает потоки для различных фоновых операций. Куда ж без этого?
С фоновыми потоками никаких проблем http://caml.inria.fr/pub/docs/manual-ocaml/libref/Thread.html
KP>Сейчас идет тенденция к увеличению количества процессоров. Зачем же целенаправленно вводить какие-то ограничения и усложнять самому себе жизнь?
Язык стал заложником реализации. Когда он появился на горизонте массовых многопроцессорных систем видно не было.
DM>>Для однопоточных программ тоже немало применений есть. Например, я делал на окамле интерактивный анализатор логов с веб-интерфейсом. Не представляю, где бы мне там пригодились параллельные потоки (с диска читать лучше последовательно, а пользователь один, и много запросов сразу не посылает). Еще делал компилятор, он и без потоков очень быстрый получился.
KP>Там бы они пригодились для раздельного чтения и анализа. Пользователей может быть больше чем 1.
С этим никаких проблем, системные потоки как уже выше писал использовать можно.
Кроме того есть очень неплохие реализации легковесных потоков например — http://ocsigen.org/lwt/manual/
А>пока я вижу только один выход — если ест что-то ресурсоемкое (или просто длинное) фоновое, то можно запускать в отдельно окамловском потоке, который будет дергать С-callback, в котором будет сначала освобождаться gil, а только потом выполняться та самая ресурсоемкая задача.
Так легко нарваться на глюки, обычно проще отдельные процессы.
А>честно говоря, не ожидал — тут столько лет разговоры были о окамле, как о полноценной замене С++, а когда руки дошли повозиться — получите, распишитесь
Реально OCaml никогда ни мог быть полноценной заменой C++, компиляторы C++ всегда лучше оптимизировали, и у C++
есть низкоуровневые возможности.
Но во времена когда массовыми компилятороми были VC 6 и gcc 2.x да и борландовские и ваткомовские компиляторы не
были антиквариатом позиция у OCaml была на порядок лучше.
Здравствуйте, FR, Вы писали:
FR>С потоками никаких проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.
Здравствуйте, Alexander Poluektov, Вы писали:
FR>>С потоками никаких проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.
AP>Я вижу противоречие в этом предложении
Как я понял у выше писавших создалось впечатление что потоки использовать в OCaml совершенно невозможно.
Это не так, потоки использовать можно и для однопроцессорных машин (и для фоновых мало загруженных потоков на
многопроцессорных) никаких различий с другими языками не будет.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, Alexander Poluektov, Вы писали:
FR>>>С потоками никаких проблем при этом нет, есть только проблемы с реальным одновременным выполнением на нескольких ядрах/процессорах.
AP>>Я вижу противоречие в этом предложении
FR>Как я понял у выше писавших создалось впечатление что потоки использовать в OCaml совершенно невозможно. FR>Это не так, потоки использовать можно и для однопроцессорных машин (и для фоновых мало загруженных потоков на FR>многопроцессорных) никаких различий с другими языками не будет.
Да понял, понял. Это был "мягкий ненавязчивый юмор"
FR>Язык стал заложником реализации. Когда он появился на горизонте массовых многопроцессорных систем видно не было.
Так легко в логику разработчиков окамловского рантайма не проникнуть. Дело в том, что 32-битная версия малоюзабельна из-за отсутствия нормальный массивов и даже чисел. А ведь массовая 64-битность тогда не просматривалась в точно такой же степени. Получается, что при создании рантайма было принято сразу два решения, одно из которых делало окамл малополезным в настоящем, а другое — должно было его сделать малополезным в будущем. Чем это можно объяснить — не понятно, разве только шуткой про инженера, который не только не должен делать ничего полезного, но даже еще немного вредить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Так легко в логику разработчиков окамловского рантайма не проникнуть. Дело в том, что 32-битная версия малоюзабельна из-за отсутствия нормальный массивов и даже чисел. А ведь массовая 64-битность тогда не просматривалась в точно такой же степени. Получается, что при создании рантайма было принято сразу два решения, одно из которых делало окамл малополезным в настоящем, а другое — должно было его сделать малополезным в будущем. Чем это можно объяснить — не понятно, разве только шуткой про инженера, который не только не должен делать ничего полезного, но даже еще немного вредить.
Логика вполне просматривается, создавали максимально эффективную реализацию для текущего массового железа.
Массивы вполне покрывали размеры тогдашней памяти.
Потом уже реализацию стало трудно изменить, хотя разработчики конечно не особо старались, вот сейчас этим
озаботились в OCamlPro (http://www.ocamlpro.com/code/2011-05-06-longval.html) и оказалось что это и не
так уж и сложно.
Здравствуйте, FR, Вы писали:
FR>Логика вполне просматривается, создавали максимально эффективную реализацию для текущего массового железа.
Но не создали. Скорее уж они создавали максимльно простую реализацию (уровня "добротная дипломная работа") с более-менее разумными возможностями и производительностью.
FR>Массивы вполне покрывали размеры тогдашней памяти.
Ну, как раз где-то во время появления и перестали покрывать. Кто же мог подумать, что окамл будут использовать на следующий год после появления? Или — страшно сказать! — через два года? А числа, с числами как? В этой колбасе тоже потребности не было?
FR>хотя разработчики конечно не особо старались
Потрясающе. Только линукс, только байткод-интерпретатор и в 2011-ом году! Самая, понимаете ли, bleeding edge, прямо как китайская космонавтика. Ну, или скорее как северокорейская космонавтика.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
FR>>Логика вполне просматривается, создавали максимально эффективную реализацию для текущего массового железа.
K>Но не создали. Скорее уж они создавали максимльно простую реализацию (уровня "добротная дипломная работа") с более-менее разумными возможностями и производительностью.
Да цели две все-таки простота и эффективность. На фоне тогдашних высокоуровневых языков вполне достигли.
FR>>Массивы вполне покрывали размеры тогдашней памяти.
K>Ну, как раз где-то во время появления и перестали покрывать. Кто же мог подумать, что окамл будут использовать на следующий год после появления? Или — страшно сказать! — через два года? А числа, с числами как? В этой колбасе тоже потребности не было?
Ну все-таки ноги растут у OCaml'а из восьмидесятых. И рантайм был создан не с нуля, а как развитие рантайма от Caml Light.
А с числами не такая и проблема, я например и с 16 битным int еще программировал.
FR>>озаботились в OCamlPro (http://www.ocamlpro.com/code/2011-05-06-longval.html) и оказалось что это и не FR>>так уж и сложно.
K>Потрясающе. Только линукс, только байткод-интерпретатор и в 2011-ом году! Самая, понимаете ли, bleeding edge, прямо как китайская космонавтика. Ну, или скорее как северокорейская космонавтика.
Здравствуйте, FR, Вы писали:
FR>Ну все-таки ноги растут у OCaml'а из восьмидесятых. И рантайм был создан не с нуля, а как развитие рантайма от Caml Light.
Ну, в 80-х у камла была совсем другая реализация, SK-машина (если память не изменяет — это вообще один из самых тормозных способов реализации ФЯ) да еще и на лиспе написанная. Так что из 80-х у окамла только диковинный, по меркам остальных ML, синтаксис. А Caml Light Лерой написал уже ближе к середине 90-х. Не такая у него с Окамлом и разница в возрасте.
FR>А с числами не такая и проблема, я например и с 16 битным int еще программировал.
Я тоже. В школе и университете.
FR>Ну не нравится жалуйся в спортлото
Так я, собственно, для этого сюда и пишу. Тут же форум техподдержки спортлото, вы не знали разве?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
FR>>Ну все-таки ноги растут у OCaml'а из восьмидесятых. И рантайм был создан не с нуля, а как развитие рантайма от Caml Light.
K>Ну, в 80-х у камла была совсем другая реализация, SK-машина (если память не изменяет — это вообще один из самых тормозных способов реализации ФЯ) да еще и на лиспе написанная. Так что из 80-х у окамла только диковинный, по меркам остальных ML, синтаксис. А Caml Light Лерой написал уже ближе к середине 90-х. Не такая у него с Окамлом и разница в возрасте.
Нет 90-91 http://caml.inria.fr/about/history.html#id2268637 для тех времен очень шустрый и экономичный.
В 95 он уже написал Caml Special Light это практически OCaml только без 'O' части.
FR>>Ну не нравится жалуйся в спортлото
K>Так я, собственно, для этого сюда и пишу. Тут же форум техподдержки спортлото, вы не знали разве?
Здравствуйте, Аноним, Вы писали:
А>Много раз читал в ДП рекомендации попробовать OCaml, как единственную альтернативу С++ в качестве языка общего назначения.
А>http://caml.inria.fr/pub/distrib/ocaml-3.12/ocaml-3.12-refman.txt
А> The Caml run-time system is not reentrant: at any time, at most one thread А>can be executing Caml code or C code that uses the Caml run-time system. А>Technically, this is enforced by a "master lock" that any thread must hold А>while executing such code.
А>это ставит крест на очень многих возможных применениях
А>
Ну так скажите, стоит ли его изучать или нет как язык для практического применения? А то я тут начал уже, вроде неплохо.
Здравствуйте, FR, Вы писали:
FR>Нет 90-91 http://caml.inria.fr/about/history.html#id2268637 для тех времен очень шустрый и экономичный. FR>В 95 он уже написал Caml Special Light это практически OCaml только без 'O' части.
Все равно компилятор в нативный код ведь только для Special появился. Ну и какой разговор о шустрости может идти в случае интепретатора байткода?
Рантайм, кстати, явно не расчитан на широко распространенный компьютер 91-го года, а вот уже в 95 совершенно ясно, что из таких коротких штанишек язык вот-вот вырастет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
'You may call it "nonsense" if you like, but I'VE heard nonsense, compared with which that would be as sensible as a dictionary!' (c) Lewis Carroll
Здравствуйте, Klapaucius, Вы писали:
K>Все равно компилятор в нативный код ведь только для Special появился. Ну и какой разговор о шустрости может идти в случае интепретатора байткода?
Это вообще один из самых шустрых интерпретаторов, быстрее того же питона в среднем в несколько раз.
Ну и тогда вообще по моему было мало функциональных языков нормально работающих на микрокомпьютерах.
K>Рантайм, кстати, явно не расчитан на широко распространенный компьютер 91-го года, а вот уже в 95 совершенно ясно, что из таких коротких штанишек язык вот-вот вырастет.
Да ну для тех объемов памяти более чем адекватно.
Re[2]: OCaml - язык общего назначения?
От:
Аноним
Дата:
10.09.11 10:52
Оценка:
Здравствуйте, Kernan, Вы писали:
K>Ну так скажите, стоит ли его изучать или нет как язык для практического применения? А то я тут начал уже, вроде неплохо.
Я когда-то начал. За бесполезностью бросил. На данный момент думаю что если хочется чего-то практичного и более-менее универсального (само собой, если говорить о функциональных языках), то стоит посмотреть на Haskell. Ну а если ты занимаешься сетевым ПО то на Erlang.
Здравствуйте, Аноним, Вы писали:
А>Я когда-то начал. За бесполезностью бросил. На данный момент думаю что если хочется чего-то практичного и более-менее универсального (само собой, если говорить о функциональных языках), то стоит посмотреть на Haskell. Ну а если ты занимаешься сетевым ПО то на Erlang.
Хаскель бы я практичным не назвал, не смотря на гораздо более широкое комьюнити и популярность, чуть лучше окамла.
По моему более-менее практичны F# и Scala.
Здравствуйте, FR, Вы писали:
FR>Хаскель бы я практичным не назвал, не смотря на гораздо более широкое комьюнити и популярность, чуть лучше окамла. FR>По моему более-менее практичны F# и Scala.
почему? меня в нём по-большому счёту не устраивает отсутсвие 64-битного компилера, и слабость gui бибилиотек. но те же претензии можно предъявить к любому языку не из первой десятки. на мой взгляд, он не менее практичен чем руби или та же скала
если ты под практичностью понимаешь поддержку jvm/clr, то да — тут даже С++ рожей не вышел
Здравствуйте, BulatZiganshin, Вы писали:
BZ>почему? меня в нём по-большому счёту не устраивает отсутсвие 64-битного компилера, и слабость gui бибилиотек. но те же претензии можно предъявить к любому языку не из первой десятки. на мой взгляд, он не менее практичен чем руби или та же скала
BZ>если ты под практичностью понимаешь поддержку jvm/clr, то да — тут даже С++ рожей не вышел
Под практичностью я в первую очередь понимаю широкий выбор достаточно качественных библиотек, с этим не только
у jvm/clr все в порядке, но и у C++ вполне нормально и у питона.
Хаскелю не только до них но и до скажем Delphi/С++ Builder далековато.
BZ>сейчас сравнил — 17490 либ на pypi против 3375 на hackage
Только количество сравнивать по моему не правильно.
FR>>Хаскелю не только до них но и до скажем Delphi/С++ Builder далековато.
BZ>а там как подсчитать?
Сложно, можно тут посмотреть http://www.torry.net/ пишут Products total: 10195
Да и из коробки с тем же дельфи сразу доступно почти все что нужно прикладному
десктоп программисту.
А>Много раз читал в ДП рекомендации попробовать OCaml, как единственную альтернативу С++ в качестве языка общего назначения.
А>http://caml.inria.fr/pub/distrib/ocaml-3.12/ocaml-3.12-refman.txt
А> The Caml run-time system is not reentrant: at any time, at most one thread А>can be executing Caml code or C code that uses the Caml run-time system. А>Technically, this is enforced by a "master lock" that any thread must hold А>while executing such code.
А>это ставит крест на очень многих возможных применениях
А>
Здравствуйте, FR, Вы писали:
FR>Под практичностью я в первую очередь понимаю широкий выбор достаточно качественных библиотек, с этим не только FR>у jvm/clr все в порядке, но и у C++ вполне нормально и у питона. FR>Хаскелю не только до них но и до скажем Delphi/С++ Builder далековато.
Использование clr-ных и jvm-ных библиотек сводит на нет преимущества Скалы/F# (впрочем, у F# 2.0 и так никаких преимуществ нет, кроме синтаксиса). Поэтому интерес они представляют только для программистов находящихся в "переходном периоде", которые пишут на F# как на C#, иногда впаивая List.fold и пайпы. Если очень хочется, из Хаскеля тоже можно вызывать любую дотнетовскую библиотеку, используя Сальсу, или любую сишную, используя FFI. Только мало кому этого хочется. А по количеству библиотек, специально разработанных под язык с целью воспользоваться всеми его преимуществами, Хаскель таки лидер среди ФЯ.
