Closed ivlevAstef closed 3 years ago
Привет @ivlevAstef ! Очень круто что постоянно поддерживаешь библиотеку! DITranquillity первый DI контейнтер который я попробовал, функционал очень удобный и простой) не стал создавать новый вопрос, опишу свою проблему тут, в общем при стандартном сценарии регистрации и получения сущностей в memory graph кажет утечки памяти на объектах типа ParsedType, я еще не настолько заимпрувил скилы по тому как устроена память, поэтому не понимаю, это плохо и я что то может быть не так делаю? или на такие вещи можно забить?
Привет @ivlevAstef ! Очень круто что постоянно поддерживаешь библиотеку! DITranquillity первый DI контейнтер который я попробовал, функционал очень удобный и простой) не стал создавать новый вопрос, опишу свою проблему тут, в общем при стандартном сценарии регистрации и получения сущностей в memory graph кажет утечки памяти на объектах типа ParsedType, я еще не настолько заимпрувил скилы по тому как устроена память, поэтому не понимаю, это плохо и я что то может быть не так делаю? или на такие вещи можно забить?
Надо проверить. Но вообще формально скорей всего он просто видит, что объект никогда не удалиться и так пишет. Эти типы создаются в момент регистрации, и пока существует контейнер, никуда не денутся. А контейнер обычно существует всё время исполнения программы.
Конечно это не исключает ситуации, что там может быть реальный retain цикл, но я у себя не замечал (может просто не обращал внимание). или возможно, что сама регистрация делается не по рекомендациям и в closure есть например ссылка на container.
Привет @ivlevAstef ! Очень круто что постоянно поддерживаешь библиотеку! DITranquillity первый DI контейнтер который я попробовал, функционал очень удобный и простой) не стал создавать новый вопрос, опишу свою проблему тут, в общем при стандартном сценарии регистрации и получения сущностей в memory graph кажет утечки памяти на объектах типа ParsedType, я еще не настолько заимпрувил скилы по тому как устроена память, поэтому не понимаю, это плохо и я что то может быть не так делаю? или на такие вещи можно забить?
Надо проверить. Но вообще формально скорей всего он просто видит, что объект никогда не удалиться и так пишет. Эти типы создаются в момент регистрации, и пока существует контейнер, никуда не денутся. А контейнер обычно существует всё время исполнения программы.
Конечно это не исключает ситуации, что там может быть реальный retain цикл, но я у себя не замечал (может просто не обращал внимание). или возможно, что сама регистрация делается не по рекомендациям и в closure есть например ссылка на container.
я запустил твой проект для steam, там наблюдается такая же картина
Привет @ivlevAstef, @SergioPerm, похожая проблема с утечкой ParsedType. Инициализируется base и firstNotSwiftType, выставляется self и он не может зарелизится.
Как вариант, проблему решает - просто возвращать другой объект:
private(set) lazy var base: ParsedType = {
...
return iter === self ? ParsedType(type: type) : iter
}
private(set) lazy var firstNotSwiftType: ParsedType = {
...
return iter === self ? ParsedType(type: type) : iter
}
@alobanov11 @SergioPerm Посмотрел. Да на самом деле была ссылка на самого себя. Поправил в 4.2.1 версии.
update arguments API into 4.3.0 version
Now if I resolve one object with arguments from more threads app can crash - because set arguments and resolve not atomic operation:
This problems actual for Provide1, Provide2... and Lazy1, Lazy2 because he using argument.
setArgs - устанавливает аргументы к указанному типу, но если это сделать из многих потоков, то аргументы будут в итоге от последнего.
первый resolve() же получит объект с аргументами от последнего, а последующие упадут.
Как решать - видимо надо сделать resolve который принимает argument-ы всеже. Да аргументы по типу, но это не отдельным расширением. В общем DIExtension походу надо удалять.