История изменений

Приношу свои извинения наСИльникам. Дырявым оказался не C, а предсказуемо GTK, точнее GObject.

GTK позволяет привязать к объекту событие с обработчиком, например к кнопке событие нажатия на нее.

Фишка в том, что удаление объекта GTK оказывается удаляет все дочерние объекты, но не удаляет привязанные события.

Т.е. создали мы 100 кнопок с обработчиком нажатия, например по килобайту на кнопку, затратили 100 Кб. Потом удалили 100 кнопок, но при этом освободилось не 100 Кб, а только 80 Кб.

Notabug зарепорчен в 2003 году, и на серьезных щщах обсуждался до 2012 года, но так и не был пофикшен, а вместо этого введена доп. фишка которая как бы удаляет обработчик вручную, правда для этого нужно хранить не только объект (кнопку) а и ID события, ассоциированного с этим объектом.

К чему это приводит.

Допустим у нас есть динамично изменяющееся поле, в моем случае это системный трей. Трейнулось приложение - создалась иконка, создался обработчик нажатия на нее. Закрыли приложение, иконку прибили, но событие так и осталось висеть. Изменило приложение свою конфигурацию, перерисовали трей или иконку, и теперь на это приложение у нас два события, при том одно из них никогда не будет обработано, ибо висит уже на несуществующем объекте. Зомби-обработчик без родителя, мать его. Оверхед небольшой, примерно килобайт-полтора на событие, и как я понял после перелопачивания кодов трех ДЕ - им пренебрегают.

Теоретически, при долгом аптайме и активном использовании Гнома\Крысы\ЛХДЕ, они будут потреблять больше и больше памяти, если только не используют какой-нибудь самопальный костыль для очистки мусора.

Что сказать. Очередное разочарование GTK и еще больше понимания, почему оно столько жрет и так тормозит.

Приношу свои извинения наСИльникам. Дырявым оказался не C, а предсказуемо GTK, точнее GObject.

GTK позволяет привязать к объекту событие с обработчиком, например к кнопке событие нажатия на нее.

Фишка в том, что удаление объекта GTK оказывается удаляет все дочерние объекты, но не удаляет привязанные события.

Т.е. создали мы 100 кнопок с обработчиком нажатия, например по килобайту на кнопку, затратили 100 Кб. Потом удалили 100 кнопок, но при этом освободилось не 100 Кб, а только 80 Кб.

Notabug зарепорчен в 2003 году, и на серьезных щщах обсуждался до 2012 года, но так и не был пофикшен, а вместо этого введена доп. фишка которая как бы удаляет обработчик вручную, правда для этого нужно хранить не только объект (кнопку) а и ID события, ассоциированного с этим обработчиком.

К чему это приводит.

Допустим у нас есть динамично изменяющееся поле, в моем случае это системный трей. Трейнулось приложение - создалась иконка, создался обработчик нажатия на нее. Закрыли приложение, иконку прибили, но событие так и осталось висеть. Изменило приложение свою конфигурацию, перерисовали трей или иконку, и теперь на это приложение у нас два события, при том одно из них никогда не будет обработано, ибо висит уже на несуществующем объекте. Зомби-обработчик без родителя, мать его. Оверхед небольшой, примерно килобайт-полтора на событие, и как я понял после перелопачивания кодов трех ДЕ - им пренебрегают.

Теоретически, при долгом аптайме и активном использовании Гнома\Крысы\ЛХДЕ, они будут потреблять больше и больше памяти, если только не используют какой-нибудь самопальный костыль для очистки мусора.

Что сказать. Очередное разочарование GTK и еще больше понимания, почему оно столько жрет и так тормозит.