Replies: 1 comment
-
@ejona86 @trustin @normanmaurer @NiteshKant Would be good to have your input on this. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
The new CompositeBuffer currently works as a concatenation of the whole-capacity memories of the component buffers.
This means that composing newly allocated buffer creates a single, larger buffer, with a
writableBytes
that is the sum of the components.It also means that the read and write offsets in the components move around with the read/write offsets in the composite buffer, and this in turn means that these offsets must line up without gaps when they are composed.
This is cool if the purpose of the composite buffer is to write to it. However, most composite buffers are probably only used for reading, extending and splitting.
In that case, it is annoying that the offsets are required to line up.
I propose that composite buffers instead become a concatenated view of the readable regions of the components.
In that case, since only the readable regions are involved, the offsets are no longer required to line up without gaps. The gaps are ignored.
That means the offsets of the components will not be influenced by any changes to the offsets of the composite buffer, so if you
decompose
the composite buffer you'll get your buffers back with the same offsets as you composed them with.It also means that the number of writable bytes in the composite buffer can at most be the writable bytes of the last component.
Perhaps such composite buffers should even be read-only, such that any write must be done with an
extendWith
call?It would be a pretty significant change to how composite buffers work.
Beta Was this translation helpful? Give feedback.
All reactions