Re: Signal disconnecting [patch, RFC]

[muppet <scott asofyet org>]

On Sat, 2003-08-16 at 21:17, Ross McFarland wrote:
> 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.

that's taken care of in remember_closure(), the function which puts the
closure into the cache, by setting an invalidation notifier on the
closure to forget_closure(), the function which removes it from the
cache.

when a closure is invalidated (made uncallable, a step that happens
before destroying a closure), it calls the invalidate notify, and gets
removed from the cache.  this happens no matter who destroys the
closure.


after looking at it most of the afternoon, the method seems rather
solid, despite my misgivings about duplication of data.  the performance
penalty should be small, since you don't sit in tight loops attaching
hundreds of signals very often.  and this stuff only happens for signals
connected directly by perl code.  it's actually a very isolated thing.


from experience writing C programs, i know that the various matching
methods can come in really handy in rare cases, so i think this would be
useful.  the way it's implemented, you can attach ten signals to the
same func, and unhook them all with one call instead of needing to
remember ten ids.  of course, it may be more efficient to disconnect by
ids, but storing them can be a headache.

-- 
muppet <scott at asofyet dot org>