however, if you use Glib::IO->add_watch or Gtk2::Helper->add_watch, i want your input.
On Saturday, August 9, 2003, at 12:14 AM, muppet wrote:
is there anybody listening who calls gperl_closure_new in his own code? i have some changes in mind for it, which would break code that uses it. (in the project's cvs, only Glib uses that function, but it's exported.)
for more info on this: SUMMARY:GPerlClosure has two members which are supplied through gperl_closure_new, name and target, which are unnecessary and incorrect. the fix requires API breakage at the binding level. the perl-level interface is unaffected, but this raises questions about GIOChannel handling.
DETAILS:gperl_closure_new is used to create GPerlClosures, GClosures which know how to marshall perl callbacks. $object->signal_connect calls gperl_signal_connect which uses GPerlClosures internally, as do the timeout, idle, and io watch functions in GMainLoop.xs.
the name is used only for debugging info that is almost always disabled. this is a string that must be copied, and therefore managed on the heap, but which is never used.
the target is the SV to which the signal is to be connected. gperl_closure_new copies this SV so it can be stored safely, resulting in an extra reference on the object to which the SV points. however, the closure object itself doesn't actually store the instance because the instance is specific to signals and closures in general don't need it. in fact, when we get into gperl_closure_marshal, we now have a contention between param_values[0] and closure->target !
as it turns out, the target should always win. fixing this involves *removing* code and reducing runtime memory usage, as well as making things more correct. however, it also involves breaking the API exported by gperl.h, because it means changing the size of GPerlClosure and removing two parameters from gperl_closure_new.
i have a patch, attached, against current CVS, which does this.
Attachment:
closure.patch
Description: application/text
the only place where this caused a problem in all of the modules in gtk2-perl-xs was with the g_io_add_watch wrapper, Glib::IO::add_watch in GMainLoop.xs. this function made use of the fact that the target was used instead of the actual instance passed to the marshaler, in order to pass the SV containing the file descriptor to the callback instead of passing a GIOChannel object (which is what the callback actually gets).
as i understand it, a GIOChannel is GLib's attempt at making something that works like perl file handles. so, i created a GPerlBoxedWrapper that returns to perl the file descriptor from the GIOChannel. this way, the io watch callbacks still get the fd they are expecting, and perl developers never know that a GIOChannel exists. this is a one-way mapping, by the way.
now, a new question is: should the GIOChannel be wrapped as a proper perl file handle (and how would you do that?) or is it okay to leave it as a fileno? and even more important, am i correct that we can just ignore the GIOChannel at the perl level and use only the file descriptor? is there any GIOChannel functionality that perl doesn't already provide?
please try out the patch and let me know what you think. -- muppet <scott at asofyet dot org>