Given TCP, is the State Design Pattern of little use when IO is non-blocking?

Question

In my TCP application, the State design pattern seemed useful as long as IO was blocking.

My SwingWorker's doInBackground() could loop through read, write, and accept states in the TCP connection by reference to the one object. See the example on wikipedia's talk page: http://en.wikipedia.org/wiki/Talk%3AState_pattern .

However, when I refactored the server to non-blocking IO, it no longer seemed useful. Select() returned a group of channels ready for IO and these were dealt with by reference to SelectionKey states in a series of if-statements.

Can anyone confirm from experience or understanding whether State Design Pattern still has utility when IO is non-blocking?

I ask because I am unsure if I have grasped State design pattern and TCP's relationship correctly.

Answer 1

Still very useful, you just have state machine per connection. select(2) (or poll(2), or epoll(7)) just give you a way of waiting on multiple channels, and dispatching events to those state machines.