Асинхронный дизель в наличии от тех же авторов, просто в отдельном крейте. Правда там есть пару неприятных особенностей, которые авторы решить не могут, а я у себя чинил костылем.
А причем тут тогда thread-local storage? И как он помогает в достижении thread-safe, что это прям обязательное условие для всех thread-safe языков, как вы писали выше?
И как в такой схеме мне делать разделяемые данные, если у каждого свой скоуп недоступный? То, что вы описали - вообще какая-то сугубо специфичная для определенных задач штука, но никак не механизм, на котором весь thread-safe построен.
Я пишу на эрланге профессионально уже больше 13 лет мне не надо его рекламировать)
Тот же rustler я использовал (да и на си nifы писал), но у них есть куча ограничений. Они блокирующие и блокируют весь шедулер, поэтому что-то долгое там не сделаешь. В целом-то это можно обойти, конечно, но это надо заморачиваться. Пример того, как в таком случае морочатся, вы можете найти в исходниках jiffy.
Вот вообще нифига не так, я буквально на днях это проверял. То есть делается функция с авейтом внутри и после авейта все делается в другом физическом потоке. Это буквально весь смысл всей этой схемы. Даже в том же расте чтобы что-то запустить в асинхронщине - оно должно быть Send + Sync, чтобы рантайм мог этим жонглировать. По поводу дорогого удовольствия. Ничто не дается бесплатно. В том же эрланге куча оверхеда и тормозов, но зато меньше вариантов прострелить себе ногу. И тут надо выбирать, что тебе важнее.
Я слабо себе представляю, как оно должно работать в случае всяких thread pool с постоянным переключением green threads между разными физическими потоками. Сам я на практике такое не использовал, но если вы мне объясните, я буду не против.
В общем-то ничего общего нет. И как бы вас thread-local storage вообще никто не заставляет использовать. А тут нет выбора в принципе, у вас буквально процессы изолированные, передавать можно только копированием (с некоторыми исключениями, но это уже не особо важные в контексте этого разговора подробности).
По сути это «ос внутри процесса». Там создаются внутренние виртуальные полностью изолированные друг от друга процессы, которые общаются друг с другом только посредством передачи сообщений. У вас физически нет разделяемой памяти и не нужно ничего синхронизировать. Это дает определенные преимущества в определенных программах, но это явно не применимо для всех возможных задач.
Тогда можно в целом считать, что в эрланге-то по сути тоже зеленые потоки, а не настоящие и исходный комментарий был неверный. Но мне кажется он был немного про другое, про то что в подобных моделях пусть даже и в зеленых потоках, но создан такой подход, что примитивы синхронизации не требуются как таковые. Потоки максимально изолированы и все межпоточное взаимодействие осуществляется через контролируемые очереди(каналы, мейлбоксы и так далее). Благодаря чему целый класс проблем просто исключается из повестки.
У меня нет такого количества экспертизы, чтобы прям туториалы для других писать. Я исходники упоминаемые в вышеприведенном комменте только сегодня посмотрел, чтобы убедиться, не ошибаюсь ли я. Было бы неловко, если бы наврал)
А еще если вы посмотрите в исходники токио, то там в одном из вариантов будет структура Semaphore с атомиком внутри. Вас это тоже триггернет и будете говорить, что это настоящий семафор?
Руководитель этих двоих даже "интернет" роняла. Все сходится.
Асинхронный дизель в наличии от тех же авторов, просто в отдельном крейте. Правда там есть пару неприятных особенностей, которые авторы решить не могут, а я у себя чинил костылем.
А причем тут тогда thread-local storage? И как он помогает в достижении thread-safe, что это прям обязательное условие для всех thread-safe языков, как вы писали выше?
И как в такой схеме мне делать разделяемые данные, если у каждого свой скоуп недоступный? То, что вы описали - вообще какая-то сугубо специфичная для определенных задач штука, но никак не механизм, на котором весь thread-safe построен.
Ну я сразу подумал, что оно похоже по описанию на process dictionary, но это штука по сути сбоку и не имеет отношения к основной работе процессов.
Да и опять же я не уверен, что именно thread local storage там используется, а это не просто схожая по концепциям вещь.
Я слабо себе представляю как работает thread local storage и beam тут ни при чем вообще.
Я пишу на эрланге профессионально уже больше 13 лет мне не надо его рекламировать)
Тот же rustler я использовал (да и на си nifы писал), но у них есть куча ограничений. Они блокирующие и блокируют весь шедулер, поэтому что-то долгое там не сделаешь. В целом-то это можно обойти, конечно, но это надо заморачиваться. Пример того, как в таком случае морочатся, вы можете найти в исходниках jiffy.
Вот вообще нифига не так, я буквально на днях это проверял. То есть делается функция с авейтом внутри и после авейта все делается в другом физическом потоке. Это буквально весь смысл всей этой схемы. Даже в том же расте чтобы что-то запустить в асинхронщине - оно должно быть Send + Sync, чтобы рантайм мог этим жонглировать.
По поводу дорогого удовольствия. Ничто не дается бесплатно. В том же эрланге куча оверхеда и тормозов, но зато меньше вариантов прострелить себе ногу. И тут надо выбирать, что тебе важнее.
Я слабо себе представляю, как оно должно работать в случае всяких thread pool с постоянным переключением green threads между разными физическими потоками. Сам я на практике такое не использовал, но если вы мне объясните, я буду не против.
В общем-то ничего общего нет. И как бы вас thread-local storage вообще никто не заставляет использовать. А тут нет выбора в принципе, у вас буквально процессы изолированные, передавать можно только копированием (с некоторыми исключениями, но это уже не особо важные в контексте этого разговора подробности).
По сути это «ос внутри процесса». Там создаются внутренние виртуальные полностью изолированные друг от друга процессы, которые общаются друг с другом только посредством передачи сообщений. У вас физически нет разделяемой памяти и не нужно ничего синхронизировать. Это дает определенные преимущества в определенных программах, но это явно не применимо для всех возможных задач.
Как из моего комментария вообще следует, что я actix использую? к слову, я его не использую.
Спасибо, я в курсе) вы можете выше найти комментарий, где я про их внутреннее устройство немного рассказывал)
Тогда можно в целом считать, что в эрланге-то по сути тоже зеленые потоки, а не настоящие и исходный комментарий был неверный.
Но мне кажется он был немного про другое, про то что в подобных моделях пусть даже и в зеленых потоках, но создан такой подход, что примитивы синхронизации не требуются как таковые. Потоки максимально изолированы и все межпоточное взаимодействие осуществляется через контролируемые очереди(каналы, мейлбоксы и так далее). Благодаря чему целый класс проблем просто исключается из повестки.
Тут согласен, в нем очень сложно (хоть и не невозможно) себе прострелить ногу при работе с потоками. Скорее всего просто не скомпилится.
https://github.com/actix/actix
а токио это про асинхронщину, а не про потоки в первую очередь.
Хотя actix сделан поверх токио, но все же это по сути эрланговая модель.
Спасибо за предложение. Я подумаю над этим. Никогда не пробовал)
У меня нет такого количества экспертизы, чтобы прям туториалы для других писать. Я исходники упоминаемые в вышеприведенном комменте только сегодня посмотрел, чтобы убедиться, не ошибаюсь ли я. Было бы неловко, если бы наврал)
А еще если вы посмотрите в исходники токио, то там в одном из вариантов будет структура Semaphore с атомиком внутри. Вас это тоже триггернет и будете говорить, что это настоящий семафор?
И? Вы там видите мьютексы или семафоры?