System of calling functions with side effects when an object goes out of scope. Scoping can be defined as gc-based scoping or stack-based scoping or a combination of the two of them in which case the behavior becomes 'release-no-later-than'.
For GC resources, users must not reference the tracked object in the dispose function else the circular dependency will keep the object in the gc's live set
System of calling functions with side effects when an object goes out of scope. Scoping can be defined as gc-based scoping or stack-based scoping or a combination of the two of them in which case the behavior becomes 'release-no-later-than'. For GC resources, users must not reference the tracked object in the dispose function else the circular dependency will keep the object in the gc's live set
(chain-resources new-resource old-resource)
Chain an older resource to a newer (derived) one such that the older resource cannot go out of gc scope before the newer resource has. This allows you to create 'sub' objects and ensure the parent object cannot get cleaned up before 'sub' objects.
This is a very costly way of doing this and if misused it can lead to false OOM situations. The reason is that the link to the parent object is only broken after the GC run so it takes as many gc runs as the depth of the object graph so your code can easily create object graphs faster than it will cause gc runs.
Because of this it is much better to just have a member variable that points back to the parent.
Chain an older resource to a newer (derived) one such that the older resource cannot go out of gc scope before the newer resource has. This allows you to create 'sub' objects and ensure the parent object cannot get cleaned up before 'sub' objects. This is a very costly way of doing this and if misused it can lead to false OOM situations. The reason is that the link to the parent object is only broken *after* the GC run so it takes as many gc runs as the depth of the object graph so your code can easily create object graphs faster than it will cause gc runs. Because of this it is much better to just have a member variable that points back to the parent.
(in-stack-resource-context?)
Returns true if the current running code is inside a stack resource context.
Returns true if the current running code is inside a stack resource context.
(releasing! & body)
Stole this name from Neanderthal - this is just a far better and faster thing to write.
Synonym for stack-resource-context
.
Stole this name from Neanderthal - this is just a far better and faster thing to write. Synonym for [[stack-resource-context]].
(stack-resource-context & body)
Stack resource context. When this context unwinds, stack resource declared within will be released.
Stack resource context. When this context unwinds, stack resource declared within will be released.
(track item)
(track item {:keys [track-type dispose-fn]})
Track a resource. If the item inherents from PResource or is a clojure fn, or a Runnable object then it can be cleaned up by the stack system with no further dispose function. Objects tracked by the gc need to have a dispose fn that does not reference the tracked object.
Using stack-based resource tracking when there is no stack resource context open will generate a warning every time as it guarantees a memory leak.
Options:
:tracking-type
- Track types can be :gc, :stack, [:gc :stack] or :auto with :gc being the default
tracking type.
:gc
- Cleanup will be called just after the original object is garbage collected.:stack
- Get cleaned up when the stack resource context is cleaned up. This means a stack
returns context must be open.:auto
: Will use stack if a stack is open and gc if one is not.Track a resource. If the item inherents from PResource or is a clojure fn, or a Runnable object then it can be cleaned up by the stack system with no further dispose function. Objects tracked by the gc need to have a dispose fn that does *not* reference the tracked object. Using stack-based resource tracking when there is no stack resource context open will generate a warning every time as it guarantees a memory leak. Options: * `:tracking-type` - Track types can be :gc, :stack, [:gc :stack] or :auto with :gc being the default tracking type. * `:gc` - Cleanup will be called just after the original object is garbage collected. * `:stack` - Get cleaned up when the stack resource context is cleaned up. This means a stack returns context must be open. * `:auto`: Will use stack if a stack is open and gc if one is not.
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close