CompositeByteBuf.addComponent ownership clarification #4760
Comments
Scottmitch
added a commit
to Scottmitch/netty
that referenced
this issue
Jan 29, 2016
Motivation: The current interface for CompositeByteBuf.addComponent is not clear under what conditions ownership is transferred when addComponent is called. There should be a well defined behavior so that users can ensure that no leaks occur. Modifications: - CompositeByteBuf.addComponent should always assume reference count ownership Result: Users that call CompositeByteBuf.addComponent do not have to independently check if the buffer's ownership has been transferred and if not independently release the buffer. Fixes netty#4760
|
@trustin ping again |
Scottmitch
added a commit
that referenced
this issue
Feb 2, 2016
Motivation: The current interface for CompositeByteBuf.addComponent is not clear under what conditions ownership is transferred when addComponent is called. There should be a well defined behavior so that users can ensure that no leaks occur. Modifications: - CompositeByteBuf.addComponent should always assume reference count ownership Result: Users that call CompositeByteBuf.addComponent do not have to independently check if the buffer's ownership has been transferred and if not independently release the buffer. Fixes #4760
pulllock
pushed a commit
to pulllock/netty
that referenced
this issue
Oct 19, 2023
Motivation: The current interface for CompositeByteBuf.addComponent is not clear under what conditions ownership is transferred when addComponent is called. There should be a well defined behavior so that users can ensure that no leaks occur. Modifications: - CompositeByteBuf.addComponent should always assume reference count ownership Result: Users that call CompositeByteBuf.addComponent do not have to independently check if the buffer's ownership has been transferred and if not independently release the buffer. Fixes netty#4760
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If all goes well
CompositeByteBuf.addComponentwill take "ownership" (will callrelease()) of the parameter. However there are cases where this is not the case. For example if theCompositeByteBufhas been releasedaddComponentmay throw anIllegalReferenceCountExceptionand not release the parameter. At the very least the interface should be clarified so that the caller can understand expectations. However I would like see if there are any objections toCompositeByteBuf.addComponentalways assuming "ownership" of the parameter. This would be analogous to aChannel.writealways assuming responsibility of the parameter even if the underlying transport cannot actually support the write operation.The text was updated successfully, but these errors were encountered: