On Wed, May 21, 2008 at 9:36 AM, 이희승 (Trustin Lee) <[EMAIL PROTECTED]> wrote:
> For now, slicing might copy or might not copy depending on the specified > position and length. If the requested slice belongs to one ByteBuffer, no > copy will be performed. Otherwise a new ByteBuffer will be created and > zero-copy in not realized. Decoder implementor needs to understand this and > implement the decoder properly to achieve zero-copy. State machine based > decoders should not have a problem with this IMHO. Please let me know if I > am missing something. > > To provide more perfect zero-copy, we need to introduce a new type which > wraps one or more ByteBuffers. Its implementation could be similar to > ByteBufferQueue, but it's different in that its length is fixed and it looks > exactly like ByteBuffer. It's because ByteBuffer cannot be extended. > Should we provide this? I think we can. The problem is that we need to > write a whole bunch of JavaDoc for the new buffer class, although it's just > one time task. > It would also be possible to provide a more general method that returns an Iterable<ByteBuffer>, but of course this would be harder for callers to work with. Personally I prefer the "wrapper" option. Another possible problem in introducing a new buffer type is overhead. > ByteBufferQueue is already composite, and its elements can be composite - > index calculation cost might neutralize the advantage of zero-copy. On the > other hand, we can keep the index calculation depth to two level at maximum > and to one level in most cases, so it might not be a big problem. :) > > So, I'm up for introducing a new type. However, there was also a request > that we have to use ByteBuffer as first citizen. Please let me know again > if there's an issue with introducing a new type that we are missing. Another advantage of a "ByteBuffer wrapper" is that it could include a free()/dispose() method that would allow us to encapsulate disposal behaviour (e.g. returning the ByteBuffer to a pool). This is especially useful when you're doing complicated stuff with buffers, like slicing them into bits and using them in different places. Cheers Rich
