r
А что в body происходит?
Size: a a a
2020 November 23
S
do_runtime_invoke - Вот ваш вызов execute ) покрошеный колстек на 35-40 походит на твою лямбду и еще раз вход в инвоук.
L
потом снимаю дамп потоков - вижу что висит на mutex.lock
А если reentrant mutex использовать?
r
Если используется асинк нужно брать его примитивы синхронизации.
E
red75prime
Если используется асинк нужно брать его примитивы синхронизации.
почему?
KA
в body в основном вызов методов из Registry, манипуляция hashmap и очереди
KA
асинк используется в C#, в rust я их не использую
r
почему?
Асинк - это кооперативная многозадачность. Блокировка потока другими примитивами синхронизации вызовет проблемы.
E
red75prime
Асинк - это кооперативная многозадачность. Блокировка потока другими примитивами синхронизации вызовет проблемы.
вы имеете в виду в рамках rust?
r
вы имеете в виду в рамках rust?
Вообще. Асинк из С# тоже не любит синхронные локи.
E
red75prime
Вообще. Асинк из С# тоже не любит синхронные локи.
по поводу rust: есть асинхронный tokio::sync::Mutex, но в документации к этому асинхронному Mutex написано " it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code"
r
асинк используется в C#, в rust я их не использую
Это так не работает. Если нужно подождать в асинхронной таске, то нужно вернуть управление скедулеру.
r
В общем, нужно смотреть в документации как организовать await в нативном коде.
KA
сейчас буду копать в сторону таких локов, там действительно есть callback функции из rust в C#, однако там нет yield, да и по дампу не видно второго захода в execute - сейчас я это более подробно посмотрю
YB
по поводу rust: есть асинхронный tokio::sync::Mutex, но в документации к этому асинхронному Mutex написано " it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code"
tokio типа умеет делать магию с заблокированными задачами, но я бы на это на всякий случай не полагался
KA
red75prime
Это так не работает. Если нужно подождать в асинхронной таске, то нужно вернуть управление скедулеру.
А почему не работает? Какая разница откуда вызван библиотечный метод? Другой вопрос что с точки зрения эффективности использования CPU это может быть не так хорошо. Правда я мало что смогу с этим сделать - врядли возможно найти асинхронный lock на rust который будет работать через C# шедулер.
S
Я все таки за то чтобы не выдумывать магию. println!() в начале и в конце ф-ции execute вам поможет :)
r
по поводу rust: есть асинхронный tokio::sync::Mutex, но в документации к этому асинхронному Mutex написано " it is ok and often preferred to use the ordinary Mutex from the standard library in asynchronous code"
Да, я не прав. Это зависит от реализации асинка. Tokio для многопоточного рантайма использует work-stealing thread pool. Если один поток заблокировался, то другие возьмут на себя обработку готовых к выполнению футур. В .NET для асинка тоже могут использоваться разные контексты синхронизации. Некоторые используют один поток выполнения. Нужно смотреть что используется в unity
KA
red75prime
Да, я не прав. Это зависит от реализации асинка. Tokio для многопоточного рантайма использует work-stealing thread pool. Если один поток заблокировался, то другие возьмут на себя обработку готовых к выполнению футур. В .NET для асинка тоже могут использоваться разные контексты синхронизации. Некоторые используют один поток выполнения. Нужно смотреть что используется в unity
Там точно один поток - так как это UI поток, он активно работает с видеокартой
KA
Я все таки за то чтобы не выдумывать магию. println!() в начале и в конце ф-ции execute вам поможет :)
видимо, там правда все в лог надо будет писать, так как библиотека, возможно каким-то странным образом получается рекурсия