According to a Google engineer it’s not.
[rul=http://paultyma.blogspot.com/2008/03/writing-java-multithreaded-servers.html]Writing Java Multithreaded Servers - whats old is new [/url]
Any thoughts.
Surely NIO has its downsides:
- own code complexity
- slightly less performance than recent threading models
- horribly designed java.nio API
One upside remains:
- few threads
Every thread requires ~1MB of RAM. With thousands of connections that is a problem, unless you want to add >8GB of RAM to your system, only for handling your threads. For true multiplexing (not request=>response) you actually need 2 threads per connection, making the memory problem even worse.
Linux NPTL is not avalible everywhere. When non blocking nio was released, these type of thread developments where clear. Its not the solution to every problem. Now that we all have multi core machines, its it any surprise that multi threaded can do well?
Even better have n threads where each handles m connections. Where n & m can be tuned.
However in my game i get big gains with simplicity of debugging and mutex management by having a single network thread. The API follows a fairly popular C api as i understand, and didn’t find it hard to use. Also thread synchronization can be quite slow, but mainly because the hotspots can’t optimize the crap out sections of code with lots of synchronization code.
[quote]I’ve encountered some very strong misperceptions
[/quote]
[quote]Then ran them for me on his 768core Azul box
[/quote]
Well yes, I imagine quite a few “misconceptions” go right out of the window when you’re working on highly specialised hardware with hundreds of cores. For the rest of us who aren’t working at google and have to deal with much more run of the mill hardware I don’t see how this is really relevant.
Well, some of the discussion revolves around the relative simplicity of doing things the “old” way (1 thread to 1 client connection).
Cas 