GNOME Bugzilla – Bug 579103
GLog default handler
Last modified: 2010-12-13 21:30:32 UTC
The additions below is where I got to for a g_log_set_default_handler at the perl level, and also making g_log_default_handler available if you want to call to it from your handler (either a default handler or a specific set_handler one). The way set_default_handler returns \&Glib::Log::default_handler is meant to correspond to the C code where the default handler must always be some particular function pointer, not NULL.
Created attachment 132736 [details] [review] wrapping g_log_set_default_handler and g_log_default_handler
Review of attachment 132736 [details] [review]: Sorry for the huge delay. One question below, otherwise the patch looks great. ::: GLog.xs @@ +207,3 @@ + default_handler_coderef = newRV_inc ((SV*) cv); + } +#endif Is the risk of someone overwriting Glib::Log::default_handler really worth having a global pointer and executing this code on startup for each and every program?
Hmm. Yes, that looks a bit unnecessary in retrospect. The current \&Glib::Log::default_handler should be good enough, and may even be desirable if someone has changed it with wrapper code or something. But what do we think of \&Glib::Log::default_handler at the perl level anyway? It seems tempting to forget that and let undef mean the default handler, even if at the C level NULL doesn't mean that (and is not allowed).
Committed with the mentioned changes. I think that it does make sense to have Glib::Log::default_handler because it allows you to have a custom log handler which just "applies advice" to Glib::Log::default_handler, i.e. it does something but then still calls Glib::Log::default_handler. I added a test case for this.
Oh, I meant whether Glib->set_default_handler should accept and return \&Glib::Log::default_handler to mean the default handler. Perhaps it would be easier if undef meant the default handler, even though the C g_log_set_default_handler() doesn't work that way (doesn't take NULL).