the Parser nulls its pointer before passing over to the Observer, which then frees the struct after copying data but *before* yielding
-
-
Replying to @mountain_ghosts
oh and local allocations are freed before yielding -- they've been copied into ruby strings by then
1 reply 0 retweets 0 likes -
Replying to @mountain_ghosts
the Parser can't pass things off to Observer *and then* clean up -- that code might not be reached
1 reply 0 retweets 0 likes -
Replying to @mountain_ghosts
you run the risk of leaking memory, or keeping a pointer that's been freed and so writing to it or freeing it later
1 reply 0 retweets 0 likes -
Replying to @mountain_ghosts
so figuring out who "owns" what and what state everything is in *before* yielding to user code is crucial and easily broken
2 replies 0 retweets 1 like -
Replying to @mountain_ghosts
the first thing you learn when writing rust is how less rigorous you were than you thought.
2 replies 0 retweets 3 likes -
Replying to @wycats
I'm trying to arrange things so there's usually only one pointer to something in existence, which is tricky
2 replies 0 retweets 0 likes -
Replying to @mountain_ghosts
borrowing is an important trick in rust and very easy to mess up.
1 reply 0 retweets 0 likes -
Replying to @wycats
even when I have multiple pointers, I've a clear idea of who should clean them up
1 reply 0 retweets 0 likes -
Replying to @mountain_ghosts @wycats
the hardest thing so far is the control flow around yielding to user code and how that failing might break your memory management
2 replies 0 retweets 1 like
yep! The fact that callbacks "just work" in rust (once you say what you need to say) is downright magic.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.