Quote:Original post by Cipher3D I think selectNow is a recent feature as I cannot find ANY tutorials at all who use selectNow.
No, it's just that the tutorials don't bother because there's no need to cover it specially - it doesnt change any of your I/O code, and you only use it if your calling code was already designed to need selectNow, so you don't need to change any of that either :).
No, the docs tell you that a method call that does *no* I/O is blocking - that cannot, by definition, affect blocking/non-blocking I/O.
As I pointed out, in *real* servers (which I've run several of), you tend to drop out of the select automatically anyway.
As explained above; select() *is* part of non-blocking I/O - whether or not the select method itself blocks - and when people say "select is non-blocking" they mean "non-blocking I/O", they just can't be bothered to say the last bit ;).
I'm not sure if we're talking semantics or something else here, I could be wrong, but I've always thought of non-blocking and blocking IO having to do with blocking threads themselves (which select does do if there isn't any IO going on). I understand what you mean by a "real" server not blocking a thread because I/O happens continuously. But in a game context, I can think of types of games where I/O won't happen nonstop (so the thread running select() gets blocked). There might be something else going on behind the scenes that I'm not aware of. Either way it's pretty confusing the way the docs say a "blocking selection operation" and so on.
Quote:Original post by Tebriel I'm not sure if we're talking semantics or something else here, I could be wrong, but I've always thought of non-blocking and blocking IO having to do with blocking threads themselves (which select does do if there isn't any IO going on).
Select can block the current thread, but the main benefit there is that you only needed one thread to do that with, as opposed to having 1 thread per connection, most of which are blocked on input at any given time. But select is also optionally given a time out value, which if set to zero, means that it is effectively non-blocking.
Back to the principles of networking, asynchronous I/O is a full duplex communication channel, am I correct? It means a server/client can write and read asynchronously from the connection, both operations can occur "at the same time".
By "the same time", read: in half duplex, you can "occupy" the channel for reading OR writting, not both at once. In asynchronous, full duplex channels, you can read and write to the same channel without having to sinalize that intention, and "block" whatever operation was running.
I guess that's what most people don't understand regarding NIO. It is a basic concept from school, so the API does not show any sign of this "underlying" logic working with the threads and the select() call. I might be making a BIG confusion here, and if that is the case, I humbly ask for someone to clarify.
I hope I'm not soo rusty as to have written nonsense here. If that is the case, I'm sure someone will undo my mistakes here ;) Also, my english is not so good, so overlook the grammar (please, don't call those ninjas of the humour portal! =)
Quote:Original post by Son of Cain asynchronous I/O is a full duplex communication channel, am I correct?
Yes. Everything that runs on TCP or UDP is (although there's room for arguments over what *ought* to constitute the definition of full-duplex when you get on to the actual physical implementation)
Cipher3D, It doesn't really have much importance in Java or C++. It's more of a low-level networking detail that says whether a connection can exchange information in both directions simultaneously (full-duplex) or just in one direction at once (half-duplex). (A channel that only goes in one direction is called 'simplex'.)
Son of Cain, I think calling asynchronous I/O 'full duplex' is not really accurate. Asynchronous simply means that the 2 sides do not have to be synchronised, and really this could apply even to a simplex connection. The implication of this in a higher level language is that a remote host can be sending you data which piles up in a buffer on your system and you don't need to immediately attend to that. Async I/O is like the mailman putting something in your mailbox and setting the flag to say something's arrived. (Java/C++ example: select().) Synchronous I/O is more like a phone call where you have to pick up the phone and listen while the message is transmitted. (Java/C++ example - one side calls a read operation and waits for the other side to call a write operation.)
Thanks, got rid of the misunderstanding ;) I already knew about the synch / asynch difference, but I was trying to stablish a connection between this concept and the high level implementation of it - which is inapropriate for many reasons, some explained.
