Вас только mono смутило?) А использование HttpListener вместо ASP.NET Core? А использование напрямую mono компилятора с указанием конкретного файла для компиляции? А подключение библиотек, через ручное скачивании dll и указанием их через -r параметр? Это не пример, это анти-пример.
А знаете какие-нибудь решения для миграции в БД, которые можно к Юнити подключить. Мне в голову только EF/EF Core приходит, но его вряд ли получиться к Юнити подключить, хотя попробовать можно :)
Ох, как мне это нравится). Пришли иксперды и начали рассказывать про DCL, volatile, memory barrier (хотя в рамках .NET рантайма тот код полностью валиден и не надо там никакого volatile, вот пример от самих MS - https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md#examples-and-common-patterns), но при этом главную проблему не заметили: Random сам по себе не thread-safe и нельзя вызывать Next из нескольких потоков. В .NET довольно давно уже есть thread-static переменная Random.Shared, которую и рекомендуется использовать.
Навороты конечно непростые, но про оверхед вы не правы. Эти "аппендеры" являются структурами нулевого размера, которые используются как типы-параметры в дженерик методе, тут нет никаких аллокаций и кастов и, скорее всего, весь код "аппендеров" будет заинлайнен JIT'ом.
В .NET 7 завесли новый GC основанный на сегментах и регионах. Возможно это влиет на стратегию возврата памяти OC. В этой статье рассказано как происходит decommit памяти в новом GC
Вас только mono смутило?) А использование HttpListener вместо ASP.NET Core? А использование напрямую mono компилятора с указанием конкретного файла для компиляции? А подключение библиотек, через ручное скачивании dll и указанием их через -r параметр? Это не пример, это анти-пример.
В репе .NET есть дизайн док на эту тему, но когда это будет реализовано неизвестно.
А знаете какие-нибудь решения для миграции в БД, которые можно к Юнити подключить. Мне в голову только EF/EF Core приходит, но его вряд ли получиться к Юнити подключить, хотя попробовать можно :)
Окей, я просто ориентировался на тот кусочек кода, который был в комментарии, тогда я вообще никаких проблем не вижу.
Ох, как мне это нравится). Пришли иксперды и начали рассказывать про DCL, volatile, memory barrier (хотя в рамках .NET рантайма тот код полностью валиден и не надо там никакого volatile, вот пример от самих MS - https://github.com/dotnet/runtime/blob/main/docs/design/specs/Memory-model.md#examples-and-common-patterns), но при этом главную проблему не заметили: Random сам по себе не thread-safe и нельзя вызывать Next из нескольких потоков. В .NET довольно давно уже есть thread-static переменная Random.Shared, которую и рекомендуется использовать.
Навороты конечно непростые, но про оверхед вы не правы. Эти "аппендеры" являются структурами нулевого размера, которые используются как типы-параметры в дженерик методе, тут нет никаких аллокаций и кастов и, скорее всего, весь код "аппендеров" будет заинлайнен JIT'ом.
А может все-таки лучше возврашать обычный инстанс структуры, чтобы вызывающий код сам решал, нужен Rc, Arc или вообще ничего.
В .NET 7 завесли новый GC основанный на сегментах и регионах. Возможно это влиет на стратегию возврата памяти OC. В этой статье рассказано как происходит decommit памяти в новом GC
А вообще, по моему мнению, за крутыми enum нужно идти в rust. Я хоть и шарпист, но мне очень нравится как enum в rust реализованы.