Question

I implemented a small client server application in Ruby and I have the following problem: The server starts a new client session in a new thread for each connecting client, but it should be possible to shutdown the server and stop all the client sessions in a ‘polite’ way from outside without just killing the thread while I don’t know which state it is in.

So I decided that the client session object gets a `stop’ flag which can be set from outside and is checked before each action. The problem is that it should not wait for the client, if it is just waiting for a request. I have the following temporary solution:

def read_client
  loop do
    begin 
      timeout(1) { return @client.gets }
    rescue Timeout::Error
      if @stop
        stop # Notifies the client and closes the connection
        return nil
      end
    end
  end
end

But that sucks, looks terrible and intuitively, this should be such a normal thing that there has to be a `normal’ solution to it. I don’t even know if it is safe or if it could happen that the gets operation reads part of the client request, but not all of it.
Another side question is, if setting/getting a boolean flag is an atomic operation in Ruby (or if I need an additional Mutex for the flag).

Answer 1

Thread-per-client approach is usually a disaster for server design. Also blocking I/O is difficult to interrupt without OS-specific tricks. Check out non-blocking sockets, see for example, answers to this question.