On Wed, 21 May 2008 08:32:21 +0900, Rich Dougherty <[EMAIL PROTECTED]> wrote:
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.
I think Daniel's idea satisfies both. ByteBufferQueue extends
Iterable<ByteBuffer>, and users still have nice access methods.
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.
This leads me to an interesting issue.
ByteBufferQueue.poll() returns ByteBuffer and we can remove it from the
internal data structure. However, we cannot return it to the pool because
there's no guarantee when user will dereference it. Explicit free method
makes sense. However, introducing the whole buffer types just because
this one method sounds like an overkill. It might be just enough with a
static method in this case? (or do we need mixin in Java? :D)
Thanks,
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
