Я тебя породил, я тебя и убью!
Н. Гоголь "Тарас Бульба".
Н. Гоголь "Тарас Бульба".
Старые ошибки или почему иногда, большое удобство плохо.
Если человеку дают очень удобное и красивое средство он теряет нюх и начинает ошибаться, конечно, потом он находит свои ошибки, и не считает, что все что блестит золото , но все таки. Как пример можно привести мелкие ошибки в решении которых я когдато участвовал (примеры относяться к .Net).
Как известно эта платформа обладает очень хорошим свойством как сборщик мусора, вот понимание его работы и вызвало ошибку: когда теряется ссылка на объект через некоторое время этот объект будет удален, но бывают некоторые особенности. Иногда остаются скрытые ссылки на этот объект, и как следствие он остается на вечно и скрытно жрет ресурсы: например окошко с созданным в нем таймером по которому в этот окошке , что то изменяется, вызывает такую особенность: система обрабатывает это окошко по особенному. В системе есть команда: 'выполнять по таймеру событие' и вся эта система, когда вы думаете уже мертва, начинает жить по собственным правилам, и не давать сборщику мусора удалить себя, так как есть круговая зависимость окошко->таймер->система и через некоторое время все ресурсы съедены и система уже не может создавать новые компоненты. Но и умереть она не может, так как не понятно, что происходит и нужно сообщить разработчикам или умереть, одно выполнить не можем, а другое не красиво, а решение простое: когда вам что то уже не нужно разрывайте и останавливаете связи сами, а не ждите, пока это сделает система, так хоть немного дольше проживете(в смысле программы).
Я тебя породил я тебя и убью... всегда сохраняйте взаимосвязь внутри приложения родитель -> потомок. Так как поток созданный в программе обладающей выше указанным багом некогда не умрет при исключении в основном потоке и программа постепенно 'захватит мир или моск'. В данном случае поток выполняющийся в программе был создан, как отдельный процесс не связанный с основным, в деструкторе основного потока он не уничтожался и потихоньку держал ресурсы всей программы. Решение было простое создавать не новый поток, а вызывать асинхронно делегат, который заменил этот поток.
Если человеку дают очень удобное и красивое средство он теряет нюх и начинает ошибаться, конечно, потом он находит свои ошибки, и не считает, что все что блестит золото , но все таки. Как пример можно привести мелкие ошибки в решении которых я когдато участвовал (примеры относяться к .Net).
Как известно эта платформа обладает очень хорошим свойством как сборщик мусора, вот понимание его работы и вызвало ошибку: когда теряется ссылка на объект через некоторое время этот объект будет удален, но бывают некоторые особенности. Иногда остаются скрытые ссылки на этот объект, и как следствие он остается на вечно и скрытно жрет ресурсы: например окошко с созданным в нем таймером по которому в этот окошке , что то изменяется, вызывает такую особенность: система обрабатывает это окошко по особенному. В системе есть команда: 'выполнять по таймеру событие' и вся эта система, когда вы думаете уже мертва, начинает жить по собственным правилам, и не давать сборщику мусора удалить себя, так как есть круговая зависимость окошко->таймер->система и через некоторое время все ресурсы съедены и система уже не может создавать новые компоненты. Но и умереть она не может, так как не понятно, что происходит и нужно сообщить разработчикам или умереть, одно выполнить не можем, а другое не красиво, а решение простое: когда вам что то уже не нужно разрывайте и останавливаете связи сами, а не ждите, пока это сделает система, так хоть немного дольше проживете(в смысле программы).
Я тебя породил я тебя и убью... всегда сохраняйте взаимосвязь внутри приложения родитель -> потомок. Так как поток созданный в программе обладающей выше указанным багом некогда не умрет при исключении в основном потоке и программа постепенно 'захватит мир или моск'. В данном случае поток выполняющийся в программе был создан, как отдельный процесс не связанный с основным, в деструкторе основного потока он не уничтожался и потихоньку держал ресурсы всей программы. Решение было простое создавать не новый поток, а вызывать асинхронно делегат, который заменил этот поток.
И будьте внимательны к мелочам, лучше самому все уничтожить в деструкторе и не делать асинхронно, то что можно сделать проще и синхронно, чем надеяться на ум среды разработки - она только помощь, а не решение.
No comments:
Post a Comment