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 thread waits to be notified that the receiving thread has
finished processing the ByteBuffer, this appears to be safely
transferred. This is for server mode.
Then there is async send, this is for client mode, here the calling
thread doesn't wait for the receiving thread.
Have a look in com.sun.jini.jeri.internal.mux.Session, here the
OutputStream uses a ByteBuffer which it shares via async send.
I think the answer is to defensively copy the async send ByteBuffer.
On 14/05/2014 7:14 PM, Patricia Shanahan wrote:
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 by appropriate synchronization? How are the
buffers communicated between the threads?
Patricia
On 5/14/2014 2:03 AM, Peter Firmstone wrote:
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.
