IL
Мне просто интересно чем аргументируется вот такой подход.
Я конечно догадывался.. ибо тогда как бы он в js с потоками то компилировался
Я конечно догадывался.. ибо тогда как бы он в js с потоками то компилировался
Size: a a a
2020 May 18
M
Совместный доступ к памяти - это очень глубокая кроличья нора. Инструмент мощный, но чертовски опасный. Неисчерпаемый источник неожиданных багов. Часто - багов, приводящих к уязвимостям.
IL
Но иногда это нужно.
Ну вот как минимум общий синглтон который есть коннектом к БД.
Вот как теперь с этим быть ))
Ну вот как минимум общий синглтон который есть коннектом к БД.
Вот как теперь с этим быть ))
M
Изолирующая многозадачность намного проще и безопаснее. При том, что обеспечивает вполне достаточную для большинства сценариев мощность
IL
Я надеялся что авось сюда завезли что то вроде Горутин
IL
Или каналов, или ещё какой то хитрый механизм ))
M
Но иногда это нужно.
Ну вот как минимум общий синглтон который есть коннектом к БД.
Вот как теперь с этим быть ))
Ну вот как минимум общий синглтон который есть коннектом к БД.
Вот как теперь с этим быть ))
А почему и не иметь отдельный инстанс в каждом потоке? Доступ же всё равно асинхронный
IL
А как тут эти изоляты организованы под капотом?
Оно поднимает новый инстанс виртуалки как в ноде, или как то попроще ?
Хотя ивент луп же будет новый в новом потоке..
Оно поднимает новый инстанс виртуалки как в ноде, или как то попроще ?
Хотя ивент луп же будет новый в новом потоке..
M
Да, в каждом изоляте свой ивент-луп
IL
А почему и не иметь отдельный инстанс в каждом потоке? Доступ же всё равно асинхронный
Ну допустим у меня орм, 100 ентити и столько же репозиториев.
Соответственно для каждого изолята мне надо инициировать целый комбайн
Соответственно для каждого изолята мне надо инициировать целый комбайн
IL
Выделение памяти, инстанциирование... Куча времени и ресурсов
M
Ну допустим у меня орм, 100 ентити и столько же репозиториев.
Соответственно для каждого изолята мне надо инициировать целый комбайн
Соответственно для каждого изолята мне надо инициировать целый комбайн
Не звучит проблемой. Отдельный вопрос - нужен ли доступ из одного сервиса ко всем?
M
Я бы, разумеется, что для Ноды, что для Дарта на сервере рекомендовал микросервисную архитектуру
🅵
Я бы, разумеется, что для Ноды, что для Дарта на сервере рекомендовал микросервисную архитектуру
++++++
🅵
Ваще никаких проблем
🅵
Связывай все брокером и масштабируй хоть до бесконечности
IL
Я бы, разумеется, что для Ноды, что для Дарта на сервере рекомендовал микросервисную архитектуру
Это само собой
У меня проблема в том что есть много математики.
На ноде считать ее... Свои нюансы из-за специфического number.
Но считается то она синхронно и тяжело.
И вот в этом случае идеально отдавать на определенные запросы отдельный поток, и пускай он там мапит данные и считает, не блокируя основной поток приложения
У меня проблема в том что есть много математики.
На ноде считать ее... Свои нюансы из-за специфического number.
Но считается то она синхронно и тяжело.
И вот в этом случае идеально отдавать на определенные запросы отдельный поток, и пускай он там мапит данные и считает, не блокируя основной поток приложения
M
Это само собой
У меня проблема в том что есть много математики.
На ноде считать ее... Свои нюансы из-за специфического number.
Но считается то она синхронно и тяжело.
И вот в этом случае идеально отдавать на определенные запросы отдельный поток, и пускай он там мапит данные и считает, не блокируя основной поток приложения
У меня проблема в том что есть много математики.
На ноде считать ее... Свои нюансы из-за специфического number.
Но считается то она синхронно и тяжело.
И вот в этом случае идеально отдавать на определенные запросы отдельный поток, и пускай он там мапит данные и считает, не блокируя основной поток приложения
Идеальная задача для изолята
IL
Мне интересно, а изолят легче ли чем воркер у ноды?
M
Мессаджем отдаёшь запрос, изолят считает, мессаджем отдаёт ответ.