ByteBuffer is a subclass of Buffer, whose documentation says, under
Thread Safety, Buffers are not safe for use by multiple concurrent
threads. If a buffer is to be used by more than one thread then access
to the buffer should be controlled by appropriate synchronization.
Is access controlled
Actually an alternative could be to use future send for all transfers,
except for eof, which can be safely used for async send since the byte
buffer doesn't change after eof.
On 14/05/2014 7:55 PM, Peter Firmstone wrote:
There are two methods of transfer, one, future send, where the
original
All you need to do is dup the buffer. That gives you independent fields for
position and limit, which is what is not thread safe. You do need a
synchronization section around that dup, but that is a very fast operation.
You can also use the read only view of the buffer. Bryan
On May 14,
Hmm, it already does that, I wonder if this is safe for direct ByteBuffer's?
Visibility is one issue, the second is mutual exclusion. I think mutual
exclusion is ok, not sure about visibility.
On 14/05/2014 8:01 PM, Peter Firmstone wrote:
Actually an alternative could be to use future send
One of the things I like about JERI is it's multiplexing and multithreaded.
What I don't like about JERI is, it passes ByteBuffers between calling
threads and pool threads.
Who can guess what's wrong with that?
Peter.
Thanks Bryan,
That's done the trick, the OutputStream that contained the ByteBuffer
was reliant on the mux output thread changing the state of position,
limit and mark.
Now the duplicate has it's own state and is published safely, the
OutputStream then waits for the mux output thread to
Excellent.
On May 14, 2014, at 9:07 AM, Peter Firmstone j...@zeus.net.au wrote:
Thanks Bryan,
That's done the trick, the OutputStream that contained the ByteBuffer was
reliant on the mux output thread changing the state of position, limit and
mark.
Now the duplicate has it's own
