Я хотел бы связать язык сборки мусора (в частности, он использует почтенный Boehm libgc) с семейством API glib.
glib и gobject используют внутренний подсчет ссылок для управления временем жизни объекта.Обычный способ обернуть их - использовать одноранговый объект со сборщиком мусора, который содержит ссылку на объект glib и который удаляет ссылку, когда одноранговый узел завершается;это означает, что объект glib сохраняется, пока приложение использует одноранговый узел.Я делал это раньше, и это работает, но это довольно болезненно и имеет свои проблемы (такие как создание двух пиров одного и того же базового объекта).
Учитывая, что у меня есть все накладные расходысборщик мусора в любом случае , в идеале я хотел бы просто отключить подсчет ссылок в glib и использовать сборщик мусора для всего.Это упростит интерфейс до бесконечности и, будем надеяться, повысит производительность.
На первый взгляд, это может показаться довольно простым - подключить финализатор сборщика мусора к финализатору объекта glib и переопределить функции ref и unref.быть noops --- но дальнейшие исследования показывают, что это нечто большее: например, glib очень любит хранить свои собственные пулы распределителей, и, конечно, я позволю ему сделать так, чтобы сборщик мусора предполагал, что все в пуле живоеи он протечет.
Действительно ли можно убедить glib использовать libgc?Если да, то с какими еще проблемами я могу столкнуться?Какое влияние на производительность glib заставило бы все выделения проходить через libgc (в отличие от использования оптимизированных распределителей, в настоящее время находящихся в glib)?
(Документы glib говорят, что он должен чисто взаимодействовать с сборщиком мусора...)