Здравствуйте, novitk, Вы писали:
N>Здравствуйте, gandjustas, Вы писали:
N>Непонятно почему .net isolator должен "захватить все", если тут не только zero sharing с сериализацией, как у отдельного процесса, но еще и гимор от двух разных vm. Одну память заколебешься считать — две managed + натив.
То есть запускать кучу докер контейнеров на одном хосте для одного приложения и общаться между ними веб-сервисами это норм, а "считать память" в процессе это что-то запредельное?
Здравствуйте, novitk, Вы писали:
G>>Я думаю изоляция и плагины на базе WASM в ближайшее время захватят всё.
N>В wasm будет нужна полная копия рантайма со своим gc и плюшками? Тогда это такой же костыль как запуск CPython внутри .net/jvm.
Кстати, а в чем отличие от AppDomain ?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>То есть запускать кучу докер контейнеров на одном хосте для одного приложения и общаться между ними веб-сервисами это норм?
Ты не правильно используешь докер и веб-сервисы, они для другого.
Если серьезно и без strawman, то я сравниваю предложенный .net isolator с изоляцией процессом, как сделано например в Chrome и пока не вижу преимуществ.
G>а "считать память" в процессе это что-то запредельное?
В случае 1+ VM в процесс оно сложнее, не уверен что вообще можно одновременно профайлер к обеим подключить. В обычной связке VM+Native гимор не мал.
Здравствуйте, Serginio1, Вы писали:
N>>В wasm будет нужна полная копия рантайма со своим gc и плюшками? Тогда это такой же костыль как запуск CPython внутри .net/jvm. S>Кстати, а в чем отличие от AppDomain ?
Мне казалось, что эксперт по .NET тут ты, а не я.
В AppDomain была изоляция внутри одной VM с полным переизпользования кода, jit, единным gc и т.д. Это кстати реально rocketscience, корни росли отсюда.
Почему убрали в Core я . Мое имхо — в реальной жизни было маловостребовано так как включения даже маленького куска unmanaged убивает изоляцию.
Здравствуйте, novitk, Вы писали:
N>>>В wasm будет нужна полная копия рантайма со своим gc и плюшками? Тогда это такой же костыль как запуск CPython внутри .net/jvm. S>>Кстати, а в чем отличие от AppDomain ? N>Мне казалось, что эксперт по .NET тут ты, а не я. N>В AppDomain была изоляция внутри одной VM с полным переизпользования кода, единным gc и т.д. Это кстати реально rocketscience, корни росли отсюда. N>Почему убрали в Core я . Мое имхо — в реальной жизни было маловостребовано так как включения даже маленького куска unmanaged убивает изоляцию.
Ну и код где то единый используется, а где то и нет. Мы можем разные сборки в домены загружать.
Я не вижу большой разницы между. Просто изоляция сделана по разному
и солнце б утром не вставало, когда бы не было меня
N>>>В wasm будет нужна полная копия рантайма со своим gc и плюшками? Тогда это такой же костыль как запуск CPython внутри .net/jvm. S>>Кстати, а в чем отличие от AppDomain ? N>Мне казалось, что эксперт по .NET тут ты, а не я. N>В AppDomain была изоляция внутри одной VM с полным переизпользования кода, jit, единным gc и т.д. Это кстати реально rocketscience, корни росли отсюда. N>Почему убрали в Core я . Мое имхо — в реальной жизни было маловостребовано так как включения даже маленького куска unmanaged убивает изоляцию.
Во! https://www.rsdn.org/article/dotnet/appdomains.xml
Для каждого домена создаётся свой собственный экземпляр сборщика мусора, свои собственные настройки безопасности и собственные статические переменные.
Загрузка сборок в каждый домен происходит независимо. Таким образом, в каждом домене будет свой собственный экземпляр класса Assembly, даже если они используют одну и ту же сборку. Однако существует способ добиться того, чтобы код загружаемых сборок совместно использовался (share) разными доменами. Сборка, используемая совместно несколькими доменами, называется нейтральной по отношению к домену (domain-neutral). Режим доступа к сборкам может быть одним из трех:
Режим, в котором нейтральность к домену обеспечивается только для mscorlib.dll. Это поведение по умолчанию. Используется в случае однодоменного приложения.
Нейтральность к домену для всех сборок. Этот режим рекомендуется использовать для мультидоменных приложений, в каждом из доменов которых выполняется один и тот же код.
Нейтральность к домену для всех сборок со строгим (strong) именем. Этот режим рекомендуется использовать для мультидоменных приложений, в каждом из доменов которых выполняется разный код.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Разраб, Вы писали:
Р>Насколько практична данная фича?
Необходима. Есть два способа:
а) Для крупных плагинов лучше использовать изоляцию через процесс (Chrome, Language Server в vscode, jupyter и т.д.).
б) Для маленьких плагинов а) слишком затратно. Есть всякие протоколы типа OSGI в Ява(Eclipse), но это "мягкая" изоляция/перегрузка. "Плохой" plugin ломает хост-контейнер.
. Мое имхо — в реальной жизни было маловостребовано так как включения даже маленького куска unmanaged убивает изоляцию.
