Re: Signal disconnecting [patch, RFC]

[Ross McFarland <rwmcfa1 neces com>]

On Sat, 2003-08-16 at 21:02, muppet wrote:
> the next question would be "why isn't it implemented?"  the answer is,  
> "because there's not a clean way to do it."   
> g_signal_handlers_disconnect_by_func() takes a pointer to a C function,  
> and as such is useless for language bindings.  even the API reference  
> says so.  the real thing to do would be to bind  
> g_signal_handlers_disconnect_matched(), for which disconnect_by_func()  
> is merely a convenient wrapper.
>
> most of the signal functions actually work with GClosures, which are  
> GLib's representation of functions as first-class objects.  the perl  
> bindings completely replace the idea of a GClosure with a perl code  
> reference[3].
>       GPerlClosure, the bindings' specialized version of GClosure which  
> knows how to marshal perl subroutines, stores a copy of the scalar that  
> points to the code to be run.  if we wanted to look up signal handlers  
> by function, we'd have to look through the lists of GClosures for  
> matching callback SVs --- but the closure lists are private to  
> libgobject.
>
> that means that in order to implement  
> (disconnect|block|unblock)_by_func or  
> (disconnect|block|unblock)_matched, the bindings actually have to keep  
> their own list of all the GPerlClosures connected via  
> gperl_signal_connect.
>
> i do have a working implementation that i whipped up while trying to  
> answer this message, but i am hesitant to commit it, because i don't  
> really like the solution (duplication of data, overhead and performance  
> penalties, general fragility).
>
> the code is attached, please let me know what you think.

would there have to be hooks in the other ways of disconnecting signal
callbacks to remove stuff from the binding's table. i'm not sure how the
table would know that something was disconnected out from under it with
the Glib::Signal->disconnect($handler_id) and other such methods.

-rm