Если твой класс наследован от Script - создается 1 экземпляр, всё остальное работает так - как ты заставишь это работать.Сейчас раскрою вопрос. Как выглядит использование моей серверной dll на c#? Скажем при запросе от пользователя, создается новый handler? или же есть лишь один instance моей серверной логики, и мне нужно будет параллелить самому? Извиняюсь за вопрос, если где-то эта тема раскрыта, хотел бы глянуть.
ООП тут как мне кажется не причем. В рамках ооп оно могло бы работать как угодно. Я просто хотел узнать, если я буду что-то долгое делать в обработчике, то скажется ли это на обработку других пользователей. Но ты в целом ответил на мой вопрос.нихуя не понял как будто бы вопроса нормально, но
каждый клиентский запрос обрабатывается с помощью своего собственного экземпляра обработчика, для каждого клиента он свой, так работает ооп
рейдж или что-то ещё тут в целом не при чём
попробуй пример привести, что ты имеешь ввиду
Понял, спасибоЕсли твой класс наследован от Script - создается 1 экземпляр, всё остальное работает так - как ты заставишь это работать.
В таком случае вопрос не в "обработчике"(по идее это объект, экземпляр класса, но пусть будет обработчик) а в потоках. Если ты заблочишь главный поток на N кол-во операций - то офк будет небольшая задержка. Если это запрос в бд/сторонний сервис выноси это в асинхронные таскиООП тут как мне кажется не причем. В рамках ооп оно могло бы работать как угодно. Я просто хотел узнать, если я буду что-то долгое делать в обработчике, то скажется ли это на обработку других пользователей. Но ты в целом ответил на мой вопрос.
Спасибо
То есть я правильно понимаю, что выполнение RemoveEvent'а например будет происходить в главном потоке?В таком случае вопрос не в "обработчике"(по идее это объект, экземпляр класса, но пусть будет обработчик) а в потоках. Если ты заблочишь главный поток на N кол-во операций - то офк будет небольшая задержка. Если это запрос в бд/сторонний сервис выноси это в асинхронные таски
Аааа. Я не так прочитал с первого раза. Сейчас возникли вопросы. То есть создается один, вообще? Как синглтон? Или один на каждого клиента как выразился Inoi?Если твой класс наследован от Script - создается 1 экземпляр, всё остальное работает так - как ты заставишь это работать.
Один, если ты хочешь получить доступ с другого объекта - сделай автосвойство Instance и в пустом конструкторе присвой Instance = this. Те самые цветные надписи при старте сервера - это и есть инициализация классов, наследуемых от script + парсинг всех евентов и командАааа. Я не так прочитал с первого раза. Сейчас возникли вопросы. То есть создается один, вообще? Как синглтон? Или один на каждого клиента как выразился Inoi?
Вызов метода с атрибутом RemoteEvent - да, 99.999% из главного потока. А вот то, как он будет работать внутри - это уже другой вопрос. Рейдж имеет удивительное свойство. Даже если ты не создаешь явно новые потоки - при использовании асинхронной таски, прямо во время таски он может "перейти в другой поток". Собственно если включить api-thread-debugging, то ты увидишь варнинг посреди таски. Это достаточно странно, ведь асинхронные таски под капотом это можно сказать корутина, и без дополнительных потоков в тредпуле они не должны туда перескакивать, но у рейджа другие планы, либо я не до конца понимаю этот момент(как он работает под капотом). В любом случае, проблема асинхронных скачков по потокам решается так же, как и в любом .net приложении, либо же можно вызывать NAPI.Task.WaitForMainThread() после какого либо await (например запрос в стороннюю api)То есть я правильно понимаю, что выполнение RemoveEvent'а например будет происходить в главном потоке?