Simone, > On 20 Feb 2018, at 20:19, Simone Bordet <simone.bor...@gmail.com> wrote: > > Hi, > > On Tue, Feb 20, 2018 at 8:35 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote: >> If by copies you mean allocating new buffers and feeling them with the same >> contents, then you are right. No copies are made. > > I mean that you call user code with a ByteBuffer produced from a > slice() of an internal ByteBuffer.
That should be the case. > The CF mechanism must ensure that the content of the internal > ByteBuffer is not changed (for example by clearing it and reading from > the network) before all CFs associated with sliced ByteBuffers > generated from the internal ByteBuffer are completed. > >> However there is a natural need for multiple passes over the buffers, both >> being sent and received. These are unavoidable transformations performed by >> SSL >> and WebSocket masking. > > Sure. > >> As for the WHOLE message, there's no way an implementation can provide a >> zero-copy >> solution. > > Leaving SSL aside, I don't see why not ? Optimistically, if the whole message is read from the underlying socket in one native read ( small messages ), then the whole message will be in a single byte buffer, zero copy. If not, then to re-assemble the whole message into a single byte buffer will require some copying ( there is no composite byte buffer). The whole message in the Java EE API is represented by a single byte buffer. The Java SE API does not suffer this issue. -Chris.
