Havoc's note about using GClosures



Hi,

I think Havoc had a good point when he mentioned that since the straight C
callbacks are the more used code paths, and GClosures have a notable
overhead over simple C callbacks, maybe the implementation of interfaces
that support both C callbacks and closures should be changed to use the
former for the actual callback.
I.e. all the current implementations use GClosures internally, and the C
version simply calls the _closure version with a CClosure created on the
fly. A much better approach would be to have internal, auxillary C
callbacks that call GClosures.
So instead of 

something_new (BonoboSomethingFn callback, gpointer user_data)
{
	return something_new_closure (g_cclosure_new (callback, user_data, NULL));
}

something_new_closure (GClosure *closure)
{
	/* Store the closure */
}

we would have

something_new (BonoboSomethingFn callback, gpointer user_data)
{
	/* ... */
}

something_new_closure (GClosure *closure)
{
	/* Of course the closure needs to be stored so it can be unref'd
	 * in the destructor */
	return something_new (something_closure_proxy, closure);
}

I don't think this change would require API changes. The only place I can
imagine API changes are where the _construct functions are passed
GClosures.

Opinions?

-- 
   .--= ULLA! =---------------------.   `We are not here to give users what
   \     http://cactus.rulez.org     \   they want'  -- RMS, at GUADEC 2001
    `---= cactus cactus rulez org =---'
Carson törvénye:  Jobb gazdagnak és egészségesnek lenni, mint szegénynek és betegnek.





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]