On 11/6/06, Robert Greig <[EMAIL PROTECTED]> wrote:
On 06/11/06, Vinod Panicker <[EMAIL PROTECTED]> wrote: > Did you try having multiple SocketIoProcessors for the acceptor? > > IIRC that should provide more concurrency to your application, and > should alleviate the starvation problem. I don't think it would. The problem is that for a given socket, reads and writes are handled by a single SocketIoProcessor. Reads and writes cannot happen concurrently *for a given socket*.
Reads aand writes are usually memory copy between kernel buffer and Java heap. Is it really more effective to do reads and writes in a separate thread? Also the current SocketIoProcessor is biased for writes, which can
cause problems if a server app has to buffer up responses to be sent back to a client that is doing a sustained period of writes.
Could you please explain why the current SocketIoProcessor is biased for writes? It always stops writing and waits for OP_WRITE whenever the kernel buffer is full (i.e. SocketChannel.write() returns 0). Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
