On Fri, 2008-08-08 at 13:32 +0200, Dirk Meyer wrote:
> + # We should connect weakly so that if the we're destroyed we
> + # automatically disconnect from the signal. But that doesn't
> + # work somehow and beacon stops working. So we just connect.
> + # This special case is about the be removed so we can ignore
> + # the missing disconnect.
> + func = func.connect_once
> # connect self as callback
> func(self)
These sorts of comments like "that doesn't work somehow" make me a bit
nervous. :) Are you really not sure why it doesn't work?
The idea behind the weak connect should be obvious: if the
InProgressCallback is destroyed, it means that no one is interested in
its result when it finishes, and so there is no reason in having it
connected to the underlying signal, whose emission that finishes the
InProgressCallback goes nowhere.
Pending InProgress objects are generally kept around by the notifier
encapsulated in timers. So there is a reference there, and when the
reference within notifier goes away, and any other reference to the
InProgress goes away, why do we need to leave it connected to the
signal? This introduces a kind of memory leak if we don't (in the sense
that a pointless object is kept around in memory until the signal is
emitted, which might be never.)
Let's demonstrate the problem:
>>> import kaa, gc
>>> s=kaa.Signal()
>>> s._callbacks
[]
# async() still does weak connect
>>> s.async(); gc.collect()
0
>>> s._callbacks
[]
>>> kaa.InProgressCallback(s); gc.collect()
<kaa.notifier.async.InProgressCallback object at 0xb7893b0c>
9
>>> s._callbacks
[<Callback for <kaa.notifier.async.InProgressCallback object at
0xb7893b0c>>]
So in the async() case, which connects weakly, when the
InProgressCallback is gone, there's no longer a callback to the signal,
as we'd like. In the latter case, with your reversion, it's still there
even after we expect it to be destroyed.
Now, this doesn't break functionality really, but it does mean that the
InProgressCallback is kept around in memory until that signal is
emitted, and it goes through the trouble of finishing the
InProgressCallback for nothing.
It seems vastly better to connect weakly and have it disconnect when the
InProgressCallback is destroyed. And this, incidentally, is how I'm
going to do __async__ anyway, so it'd be much better if you sorted out
why this breaks beacon. :)
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel
