• Post Reply Bookmark Topic Watch Topic
  • New Topic

Can non-blocking IO be this simple?  RSS feed

 
merlin bar
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In an example, two pieces of code were contrasted as blocking and non-blocking. Here they are...

Can I take as simple an approach as this to benefit from non-blocking IO with respect to multithreaded servers?
[ March 13, 2003: Message edited by: merlin bar ]
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Moving to the IO forum.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yes, though you can do more also. You can make the ServerSocketChannel nonblocking, so that accept() and other methods don't block. And it may well be worthwhile to set up a Selector to wait for different types of input. It depends on what your application is doing, and where the bottlenecks are currently (if any).
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Can I take as simple an approach as this to benefit from non-blocking IO with respect to multithreaded servers?

That particular code doesn't seem to do anything that makes non-blocking IO worthwhile. A normal BufferedInputStream and a Socket are a much simpler way to do the read input.
In a sentence, here is what makes non-blocking IO cool: You don't need to start a new thread for every connection.
It requires a completely different approach when you write a server, but it's extremely scalable.
I have to go somewhere now, but I'll post more information later.
 
merlin bar
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok thanks, I'll look forward to it.
 
David Weitzman
Ranch Hand
Posts: 1365
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I haven't read the book, but I found two examples from Java NIO's website that seem to have the right idea.
The first is a single-threaded ECHO server that can handle multiple simultanious requests. Much of the time this works just fine. The problem is that every microsecond you spend on one connection is a microsecond spent ignoring all the others. If you want low response times for all users and sustained throughput with a lot of concurrent connections, then you'd better not do anything expensive like DNS lookups or filesystem access in that main loop.
The second is a subclass of the first. A main thread select()s each connection and notes when data is available for read. Then workers in a thread pool interpret and process any newly available input. Most non-blocking servers use some variation of this general organization.
[ March 15, 2003: Message edited by: David Weitzman ]
 
merlin bar
Ranch Hand
Posts: 54
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks David, that answers my question.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!