Hi,
I have a bunch of threads which can read and write over a TCP/IP stream. Does anyone know whether it is better to get each of them to do asynchronous IO via NIO or poll them by setting a timeout on the socket?
Is there anyway to do a genuine poll of a socket? (the timeout option has to be >0 ms)
[quote]Hi,
I have a bunch of threads which can read and write over a TCP/IP stream. Does anyone know whether it is better to get each of them to do asynchronous IO via NIO or poll them by setting a timeout on the socket?
[/quote]
Since you ask (although I’m not sure it’s quite what you wanted), it’s always better to use NIO. In many cases it’s quicker (to write the code) to use IO, but there’s little other reason to use anything but NIO.
You should NEVER EVER EVER poll ANYTHING ANYWHERE if you want to achieve high performance anything. It’s one of the gross generalizations of performance tuning which is nearly always true - along with things like “Writing large programs in Visual Basic will always result in memory hungry and slow beasts” 
Well, something like that :).
By definition, polling wastes time - if you are very lucky or have a very specific situation it will be no worse than non-polling, but in general there will be many more polls than you needed to do (note: if you reduce the poll rate, by definition you simultaneously reduce the responsiveness, which is almost always undesirable)
AFAIAA there is no way to do this using standard libs; however, this is based on experimentation long ago in the past, so I may be completely wrong here :).
Why do you want to do a “genuine” poll, though? One of the many good reasons for high-level networking API’s a la java standard libs is that 99.999% of the time you have no use for low-level API’s (network sniffers are the main counter example). The best reason I can come up for wanting access to poll is that you want to benchmark low-level aspects of a system?
Well, I have written high performance servers before in C/C++ in the telecommunications arena. These have either being blocking, genuine polling or multiplexed via select(). All of these approaches have been extremely fast and each of them was best suited to the task it was employed for.
In my particular instance, each thread will be managing one TCP/IP connection, so mutliplexing with select() seems a bit heavy (since there are no other connections to select on) so that’s why I was wondering about polling (which would be simpler to implement).
If NIO is the best fit, that’s fine.
If you read my reply carefully you’ll see that I noted exceptions at several points; for brevity I didn’t expand on them. I wasn’t trying to imply you were being stupid (sorry if it looked like that), just that it was very unlikely you really wanted to use poll - you provided pretty much 0 information about what you are doing or why, forcing us to guess; most people posting a vague non-specific question on performance are doing so because they are novices and too naive to realise that their question will be unanswerable without much more info; hence I pitched my answer appropriately.
Many many poll-based systems are deployed in completely inappropriate situations whereas very few are appropriate - hence it is “nearly always true” that you should avoid it (like re-writing a standard library; if you think you need to, it’s worth double and triple checking your reasons).
…Unless you don’t care about performance, but it seemed from your post that you do.
But…why must you have a thread per connection? Again, making a guess at what you’re really asking here, I’d say that your question is irrelevant compared to the potential savings of getting rid of your threads.
How “heavy” do you fear multiplexed select to be?
W.r.t. performance, NIO select is not just for multiplexing (that’s often just a bonus).
[quote]Hi,
I have a bunch of threads which can read and write over a TCP/IP stream. Does anyone know whether it is better to get each of them to do asynchronous IO via NIO or poll them by setting a timeout on the socket?
Is there anyway to do a genuine poll of a socket? (the timeout option has to be >0 ms)
[/quote]
[] how many is a bunch?
[] what are your traffic patterns?
[] why is polling desirable? (you’ve said it’s less hassle to code so far…is that the only reason?)
[] what are the threads doing?
[] What are the options you are evaluating? “do asynchronous IO … or poll them” hides all the detail necessary to give you an answer;
[] Most importantly of all…what is “better”? Less memory usage, smaller thread-context, more thread-level-parallelism, more transparent code, lower latency, higher processing throughput … the list goes on. Hence my tongue-in-cheek first para in first reply…
Blahblahblah: Don’t worry - I didn’t take offense at your reply.
I’m coding for a server which will serve several clients (btw: a “bunch” equals 2-16 in this case 
). The server side representation was going to be a single thread per client which I had thought could just poll for input when nudged by the server - hence wondering about whether reading could be done with a poll rather than a timeout.
I’ve been thinking about what I need the server to do and I’ve decided that threads are probably unneccesary and that I probably want to go with UDP anyway (don’t need in-order delivery and most taffic won’t need acking), so I’ve kinda rendered this thread redundant.
Sorry if I was being unclear in my question - probably a reflection of me not having thought enough about what I wanted to achieve.