On Tue, Oct 19, 2010 at 10:34 AM, Jake Luciani <jak...@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 <br...@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 > > >
