thrift-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Duxbury <br...@rapleaf.com>
Subject Re: How to make use of new ByteBuffer features in Java
Date Tue, 19 Oct 2010 17:54:27 GMT
On Tue, Oct 19, 2010 at 10:34 AM, Jake Luciani <jakers@gmail.com> wrote:

> "There’s some trickiness that goes into understanding why the first element
> in the backing byte array is arrayOffset() + position(), but for right now,
> trust me that it’s the case."
>

In my experiments, the only time I could get a nonzero arrayOffset was when
I used the slice() method to get ByteBuffer that captured a view starting at
the current position. Thrift doesn't currently use slice() internally, so
you won't run into this scenario in the standard case, but if someone else
puts a ByteBuffer into the field, then all bets are off.



>
> Can you explain this? also, remaining() is defined as limit() - position()
> so when you say out.write(value.array(), value.arrayOffset() +
> value.position(), value.remaining());
> Won't you overflow?
>

No, you won't overflow. There has to be at least remaining() more bytes
after arrayOffset() + position(). I have a feeling I'm going to be writing
another blog post on this. Here's a diagram:

| 0 | 1 | 2 | 3 | 4 | 5 | 6 |
  ^    ^                      ^
  |     |                       |
  |    position          limit
array offset

The above code would get bytes 1-5 inclusive.





>
> -Jake
>
> On Tue, Oct 19, 2010 at 1:27 PM, Bryan Duxbury <bryan@rapleaf.com> wrote:
>
> > I wrote up a very quick explanation about how you might make use of the
> new
> > ByteBuffer features in Java Thrift 0.5 to achieve a zero-copy system:
> >
> >
> >
> http://blog.rapleaf.com/dev/2010/10/19/striving-for-zero-copies-with-thrift-0.5/
> >
> > I'd love your feedback!
> >
> > -Bryan
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message