75a4055d7c
DeviceMapper tasks in go use SetFinalizer to clean up C construct counterparts in the C LVM library. While thats well and good, it relies heavily on the exact interpretation of when the golang garbage collector determines that an object is unreachable is subject to reclaimation. While common sense would assert that for stack variables (which these DM tasks always are), are unreachable when the stack frame in which they are declared returns, thats not the case. According to this: https://golang.org/pkg/runtime/#SetFinalizer The garbage collector decides that, if a function calls into a systemcall (which task.run() always will in LVM), and there are no subsequent references to the task variable within that stack frame, then it can be reclaimed. Those conditions are met in several devmapper.go routines, and if the garbage collector runs in the middle of a deviceMapper operation, then the task can be destroyed while the operation is in progress, leading to crashes, failed operations and other unpredictable behavior. The fix is to use the KeepAlive interface: https://golang.org/pkg/runtime/#KeepAlive The KeepAlive method is effectively an empy reference that fools the garbage collector into thinking that a variable is still reachable. By adding a call to KeepAlive in the task.run() method, we can ensure that the garbage collector won't reclaim a task object until its execution within the deviceMapper C library is complete. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> Upstream-commit: d764d8b16624e4924b3949273089f851efa0f717 Component: engine
pkg/ is a collection of utility packages used by the Docker project without being specific to its internals.
Utility packages are kept separate from the docker core codebase to keep it as small and concise as possible. If some utilities grow larger and their APIs stabilize, they may be moved to their own repository under the Docker organization, to facilitate re-use by other projects. However that is not the priority.
The directory pkg is named after the same directory in the camlistore project. Since Brad is a core
Go maintainer, we thought it made sense to copy his methods for organizing Go code :) Thanks Brad!
Because utility packages are small and neatly separated from the rest of the codebase, they are a good place to start for aspiring maintainers and contributors. Get in touch if you want to help maintain them!