-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow cleanup of timer nodes #76
Conversation
b4ec26c
to
b9a9168
Compare
Any idea why the previous version did not work? |
To be honest, no I don't. I tried making sure the message queue was empty before calling Oh wait! Just thought of something: what if the |
@@ -23,13 +23,9 @@ function every(dt) | |||
n | |||
end | |||
|
|||
function weakrefdo(ref, yes, no=()->nothing) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was using this in fpswhen
below as well.
I added this function back and tried node = nothing
after send_value!
in core.jl. The fps node doesn't go away still.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent some time looking, but I confess I don't really understand the design of fps
well enough to be of any use.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The basic idea of fps
is that it will fire at most rate
times a second. If a signal depending on this fps signal takes longer than 1/rate
seconds to update (for example drawing a complex Compose image), it will try to give you the best possible frame rate. The implementation schedules an update 1/rate
seconds from the current update (during the current update) to accomplish this. The fps signal itself contains the time deltas between the previous update and the current one...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very helpful, thanks. So the user gets enough information to make the decision, for example, whether to show the next frame of the movie or to skip ahead to the frame that should have been scheduled at the current moment? That's very nice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or compute the correct frame from a function such as update(current_frame, dt) -> next_frame
. The animation would then just be: foldp(update, init_frame, fps(60))
, of course you are also free to use time()
and map
with fps
.
OK, this is very strange. On my machine, I can get cleanup (either on the current At For reference, on my machine
|
@timholy Sorry for not really knowing the context but does the three "node"s holding reference to each other? And do they have finalizers installed? |
So there is a known problem that having a finalizer can delay gc (reclaim of memory). Even though this doesn't mean it will delay the finalizer (for this object!), it will delay finalizers on objects it is refering to if those finalizers are installed after the finalizers of this object. I breifly tried to fix it sometime ago but didn't really see the expected effect (might be related to JuliaLang/julia#13988). I think I'll have a look at it again. Maybe tomorrow or later today since I have sth else to work on. |
without the (asking out of curiosity, not relevant to figuring out this issue) |
In that case they should be freed together in a single GC pause. |
That's nice! thanks! |
@yuyichao does |
I think I found out what was holding a reference... It was the channel, it keeps a reference around even after it's been julia> Reactive._messages.data
33-element Array{Any,1}:
(Signal{Int64}(232, nactions=1),232,Reactive.print_error)
#undef
#undef
#undef
⋮ |
No. |
Oh, very good detective work! |
This demonstrates one solution to #65 (comment). If you like it, there are likely more places it needs to be applied. The key step was to allow
WeakRef
s to be queued on_messages
.Demo (with
debug_memory=true
):