А я смотрю вы тот еще дилетант.> Про то что две модели я знаю. Я имел ввиду ithreads, но они тоже уже почти деприкейтед, т.к. костыль для венды делающий полную копию интерпретатора.
Они discouraged потому что их интерфейс ужасен. А под виндой никак не получится кроме создания полной копии интерпретатора. Такова уж кривость винды.
> Шаред структуры копирующие все данные рекурсивно это вообще смех, мало того, запаковать структуру в жсон, положить ее в шаред скаляр и распаковать в другом потоке быстрей, нежели просто сделать все шаредным. В общем быстрей бы удалили это убожество, на операционных системах с нормальными форками нe нужно.
Не зря сделали рекурсивную копию. В JSON в отдельных случаях можно, но смысла совсем нет, т.к. Data::Dumper + eval отработают быстрее, да так возможны случаи когда кроме рекурсивного копирования не обойтись. Если бы вы сталкивались с подобным, то не писали бы подобное (вот я сталкивался когда работал с ithreads на уровне си и знаю почему нужно рекурсивное клонирование)
> Согласен, не нужно. Когда нужно что-то многопоточно делать легко подключается Inline::C с pthreads.
не рекомендуют работать с perl-threads с perl-кода из-за
> А вот в язык встроить не так просто. Я как-то пробовал запустить два интерпретатора в одном процессе, так вот чтоб это сделать надо собирать интерпретатор с поддежкой этих ithreads.
Ничего сложного. Все очень просто и практически все готово для встраивания. Но это все обычный программист не разбирающися во внутренностях организации perl не сможет.
> У перла проблема я так понял в том, что он юзает глобальные переменные.
Не выдумывайте - нет там проблемы и использование глобальных переменных зависит от режима сборки. Там все ровно сделано.
> А если с поддержкой ithreads интерпретатор собирать, то он более тормозной, наверно блокировки юзает при доступе к этим переменным.
Нет там блокировок, там сделано так чтобы у не подготовленного программиста не было проблем. Не используйте threads если не нужно. Да и вообще, по логике организации там не нужны блокировки, т.к. управление отдано на программиста. Именно из-за этого интерфейс работы с потоками "очень необычный".
> Им бы лучше сделать весь стейт интерпретатора в отдельной структуре как в lua, тогда написать нормальные потоки можно будет без проблем.
Не знаю как в lua, но в perl все уже давным-давно сделано нормально (покопайте perl.h). Потоки можно ввести без проблем хоть сейчас, но я еще раз спрашиваю - для чего?