On 11/08/2012 04:57 AM, Esmond Pitt wrote:
That wouldn't have any different effect to not calling accept() at all
in blocking mode
Clearly there is a difference.
There isn't a difference. All that deregistering OP_ACCEPT does is prevent
the application from calling accept(). It has exactly the same effect as
thread-starving the accepting thread in blocking mode.
I hope you actually checked the second program I shared [1], and tried
it. What it does is simply not delay accept(), but stop accepting.
if (key.isAcceptable()) {
SocketChannel client = server.accept();
client.configureBlocking(false);
client.socket().setTcpNoDelay(true);
client.register(selector, SelectionKey.OP_READ);
System.out.println("I accepted this one.. but not any more now");
key.cancel();
key.channel().close();
When the server is ready to accept more messages, it re-binds to the
listening socket and re-registers for OP_ACCEPT.
server = ServerSocketChannel.open();
server.socket().bind(new InetSocketAddress(8280), 0);
server.configureBlocking(false);
server.register(selector, SelectionKey.OP_ACCEPT);
System.out.println("\nI am ready to listen for new messages now..");
I have written books on Java networking and I do know about this. Your 3-line
program allows > 1
connection at a time because of the backlog queue, as I have been
explaining, and when the backlog queue fills up, as it does when the
application doesn't call accept() fast enough, or at all, you get
platform-dependent behaviour. There is nothing you can do about this in Java
or indeed in C either. A program that created a ServerSocketChannel, didn't
register it for OP_ACCEPT, and then called select(), would behave in exactly
the same way.
Sorry, I do not know to explain it any better - I write code, try it..
[1]
http://esbmagic.blogspot.com/2012/11/how-to-stop-biting-when-you-cant-chew.html
cheers
asankha
--
Asankha C. Perera
AdroitLogic, http://adroitlogic.org
http://esbmagic.blogspot.com
