Free Git objects via finalizers or manually #3

2013-03-05T18:57:45-06:00

carlosmn commented

2013-03-05 18:57:45 -06:00

(Migrated from github.com)

Provide a manual way of freeing objects, but set finalizers for them
in case the user does not want to worry about memory management, which
would be useful for commits or trees, which sare typically small.

When the objects are freed manually, the finalizer is unset to avoid
double-freeing, mimicking what the go runtime does.

This is what I was saying earlier. Through some magic that I can't quite remember, doing the (*Type).Free thing lets us have the same function for both manual and automatic freeing. There's bound to be some cost to calling into the runtime package. Though unlikely, if this becomes a problem, we could look into setting the pointer to nil in Free() and exit if it's already nil, like we do in C. But I think we'll cross that bridge when we get to it.

Provide a manual way of freeing objects, but set finalizers for them in case the user does not want to worry about memory management, which would be useful for commits or trees, which sare typically small. When the objects are freed manually, the finalizer is unset to avoid double-freeing, mimicking what the go runtime does. --- This is what I was saying earlier. Through some magic that I can't quite remember, doing the `(*Type).Free` thing lets us have the same function for both manual and automatic freeing. There's bound to be some cost to calling into the `runtime` package. Though unlikely, if this becomes a problem, we could look into setting the pointer to `nil` in `Free()` and exit if it's already `nil`, like we do in C. But I think we'll cross that bridge when we get to it.

vmg commented

2013-03-05 18:59:37 -06:00

(Migrated from github.com)

Very very neat. Let's see if this segfaults tho. :)

carlosmn commented

2013-03-05 19:07:25 -06:00

(Migrated from github.com)

Only one way to find out!

Sign in to join this conversation.

No reviewers