Простите, что не дорос до вашего уровня понимания. Посыпаю голову пеплом. Пойду выкидывать форки и писать велосипеды свои реализации, а как допишу, то обещаю прийти и прочитать статью еще раз, может тогда пойму.
не любые два идущих подряд тезиса автоматически превращаются в силлогизм
Насчет силлогизма не знаю. Но как вы произвольное количество тезисов умеете в софистику превращать видно невооруженным взглядом.
Пробовали? Понравилось?
Представьте себе! И пробовал и продолжаю пробовать. И нравится вполне. Как минимум гораздо больше, чем изобретать с нуля то, что уже изобретено, но имеет "фатальный недостаток".
Раз у вас есть пулл-реквест, значит у вас есть форк. Значит никто не мешает использовать форк. Как из этого следует, что надо взять и напилить с нуля велосипед?
Де-факто стандарт в современном мире это UTF-8. Если про UTF-16 я еще могу сказать, что он там где-то в кишках винды до сих пор популярен, то про использование UTF-32 я вообще ничего не знаю, но возможно потому что у меня область немного другая и это конкретно я не сталкиваюсь.
В теории наверное что-то есть для работы как с UTF-16, так и с UTF-32, но я практически уверен, что там будет либо с проверками, либо unsafe, либо оба варианта рядом.
И в любом случае это не имеет отношения к теме поста, потому что сериализация/десериализация прямого представления в памяти делается только через unsafe. Что подразумевает, что человек в теме происходящего разбирается достаточно хорошо, чтобы сделать это корректно.
Я не знаю способа прочитать один символ именно как символ. Возможно он существует, но я не в курсе. Я знаю только про str::from _utf8, который все это проверяет и про str::from_utf8_unchecked который не проверяет и он, соответственно, unsafe. А так юникод вообще вещь странная и я не очень понимаю, что считать символом. Одну и ту же Ë можно записать и как один символ и как два (диакритический знак и Е). В общем если читать вручную посимвольно, то это верный способ по итогу рано или поздно себе ногу отстрелить.
Что-то мне подсказывает, что читать без unsafe кусок памяти в структуру/енам у вас не выйдет, это не си. А unsafe подразумевает, что вы знаете, что вы делаете.
Я может чего-то не понимаю, но по какой магии у вас работает serde_json::from_reader, который требует std::io::Read, а у вас T:async_std::io::Error? Еще интересна магия, которой можно сделать b"Файл не найден", с учетом того, что binary string literals поддерживают только ASCII. А еще хотелось бы какой-то репозиторий, где можно посмотреть, как это работает, потому что если это просто скопировать, то оно и вовсе не собирается, а половина из используемого уже достаточно давно deprecated(например тот же mplex).
Асинхронный дизель в наличии от тех же авторов, просто в отдельном крейте. Правда там есть пару неприятных особенностей, которые авторы решить не могут, а я у себя чинил костылем.
А причем тут тогда thread-local storage? И как он помогает в достижении thread-safe, что это прям обязательное условие для всех thread-safe языков, как вы писали выше?
И как в такой схеме мне делать разделяемые данные, если у каждого свой скоуп недоступный? То, что вы описали - вообще какая-то сугубо специфичная для определенных задач штука, но никак не механизм, на котором весь thread-safe построен.
Я пишу на эрланге профессионально уже больше 13 лет мне не надо его рекламировать)
Тот же rustler я использовал (да и на си nifы писал), но у них есть куча ограничений. Они блокирующие и блокируют весь шедулер, поэтому что-то долгое там не сделаешь. В целом-то это можно обойти, конечно, но это надо заморачиваться. Пример того, как в таком случае морочатся, вы можете найти в исходниках jiffy.
Вот вообще нифига не так, я буквально на днях это проверял. То есть делается функция с авейтом внутри и после авейта все делается в другом физическом потоке. Это буквально весь смысл всей этой схемы. Даже в том же расте чтобы что-то запустить в асинхронщине - оно должно быть Send + Sync, чтобы рантайм мог этим жонглировать. По поводу дорогого удовольствия. Ничто не дается бесплатно. В том же эрланге куча оверхеда и тормозов, но зато меньше вариантов прострелить себе ногу. И тут надо выбирать, что тебе важнее.
Я слабо себе представляю, как оно должно работать в случае всяких thread pool с постоянным переключением green threads между разными физическими потоками. Сам я на практике такое не использовал, но если вы мне объясните, я буду не против.
В общем-то ничего общего нет. И как бы вас thread-local storage вообще никто не заставляет использовать. А тут нет выбора в принципе, у вас буквально процессы изолированные, передавать можно только копированием (с некоторыми исключениями, но это уже не особо важные в контексте этого разговора подробности).
По сути это «ос внутри процесса». Там создаются внутренние виртуальные полностью изолированные друг от друга процессы, которые общаются друг с другом только посредством передачи сообщений. У вас физически нет разделяемой памяти и не нужно ничего синхронизировать. Это дает определенные преимущества в определенных программах, но это явно не применимо для всех возможных задач.
Простите, что не дорос до вашего уровня понимания. Посыпаю голову пеплом. Пойду выкидывать форки и писать
велосипедысвои реализации, а как допишу, то обещаю прийти и прочитать статью еще раз, может тогда пойму.Насчет силлогизма не знаю. Но как вы произвольное количество тезисов умеете в софистику превращать видно невооруженным взглядом.
Представьте себе! И пробовал и продолжаю пробовать. И нравится вполне. Как минимум гораздо больше, чем изобретать с нуля то, что уже изобретено, но имеет "фатальный недостаток".
Раз у вас есть пулл-реквест, значит у вас есть форк. Значит никто не мешает использовать форк. Как из этого следует, что надо взять и напилить с нуля велосипед?
Де-факто стандарт в современном мире это UTF-8. Если про UTF-16 я еще могу сказать, что он там где-то в кишках винды до сих пор популярен, то про использование UTF-32 я вообще ничего не знаю, но возможно потому что у меня область немного другая и это конкретно я не сталкиваюсь.
В теории наверное что-то есть для работы как с UTF-16, так и с UTF-32, но я практически уверен, что там будет либо с проверками, либо unsafe, либо оба варианта рядом.
И в любом случае это не имеет отношения к теме поста, потому что сериализация/десериализация прямого представления в памяти делается только через unsafe. Что подразумевает, что человек в теме происходящего разбирается достаточно хорошо, чтобы сделать это корректно.
Я не знаю способа прочитать один символ именно как символ. Возможно он существует, но я не в курсе. Я знаю только про str::from _utf8, который все это проверяет и про str::from_utf8_unchecked который не проверяет и он, соответственно, unsafe.
А так юникод вообще вещь странная и я не очень понимаю, что считать символом.
Одну и ту же Ë можно записать и как один символ и как два (диакритический знак и Е). В общем если читать вручную посимвольно, то это верный способ по итогу рано или поздно себе ногу отстрелить.
Что-то мне подсказывает, что читать без unsafe кусок памяти в структуру/енам у вас не выйдет, это не си. А unsafe подразумевает, что вы знаете, что вы делаете.
Надо было просить отменить предыдущие инструкции и написать рецепт блинчиков. Или чего-то другого, рецепт чего в том меме просили написать :)
Хорошая версия. Многое объясняет.
Я может чего-то не понимаю, но по какой магии у вас работает
serde_json::from_reader, который требуетstd::io::Read, а у васT:async_std::io::Error?Еще интересна магия, которой можно сделать
b"Файл не найден", с учетом того, что binary string literals поддерживают только ASCII.А еще хотелось бы какой-то репозиторий, где можно посмотреть, как это работает, потому что если это просто скопировать, то оно и вовсе не собирается, а половина из используемого уже достаточно давно deprecated(например тот же mplex).
Руководитель этих двоих даже "интернет" роняла. Все сходится.
Асинхронный дизель в наличии от тех же авторов, просто в отдельном крейте. Правда там есть пару неприятных особенностей, которые авторы решить не могут, а я у себя чинил костылем.
А причем тут тогда 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 вообще никто не заставляет использовать. А тут нет выбора в принципе, у вас буквально процессы изолированные, передавать можно только копированием (с некоторыми исключениями, но это уже не особо важные в контексте этого разговора подробности).
По сути это «ос внутри процесса». Там создаются внутренние виртуальные полностью изолированные друг от друга процессы, которые общаются друг с другом только посредством передачи сообщений. У вас физически нет разделяемой памяти и не нужно ничего синхронизировать. Это дает определенные преимущества в определенных программах, но это явно не применимо для всех возможных задач.