Skip to content

Commit

Permalink
README: Make memory management info more clear (refs #212)
Browse files Browse the repository at this point in the history
  • Loading branch information
justinfx authored Jul 21, 2019
1 parent 9f47975 commit ad4d069
Showing 1 changed file with 2 additions and 2 deletions.
4 changes: 2 additions & 2 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,7 +128,7 @@ It is an error to `Initialize` and `Terminate` multiple times in specific functi

Since this is a CGO binding, and the Go GC does not manage memory allocated by the C API, it is then necessary to use the Terminate() and Destroy() methods.

Types which are created via `New*` constructors (MagickWand, DrawingWand, PixelIterator, PixelWand,...) are managed by Go GC through the use of finalizers.
Types which are created via `New*` constructors (MagickWand, DrawingWand, PixelIterator, PixelWand,...), or created and returned by methods like `Clone()` are managed by Go GC through the use of finalizers. They are not guaranteed to be cleaned up immediately after the object is not longer in use, but rather at some point later when GC actually executes its finalizers.

If you use struct literals, you should free resources manually:

Expand Down Expand Up @@ -185,7 +185,7 @@ func main() {
}
```

Calling `Destroy()` on types that are either created via `New*` or returned from other functions calls only forces the cleanup of the item immediately as opposed to later after garbage collection triggers the finalizer for the object.
Calling `Destroy()` on types that are either created via `New*` or returned from other functions calls forces the cleanup of the item immediately as opposed to later after garbage collection triggers the finalizer for the object. It would be good practice to explicitely call `Destroy()` to ensure C memory is freed sooner rather than later, depending on how often the GC is triggered.

# License

Expand Down

0 comments on commit ad4d069

Please sign in to comment.