title: Request handling in a server using non-blocking sockets
body: <p>I'm trying to implement a simple server. The server uses non-blocking sockets and a thread pool to process each request. Currently I'm using a monitor along with a event queue to handle incoming requests. I'm having trouble with defining what my event should be - right now its a structure:</p>
  
  <pre><code>struct eventQueueNode {
  int clientSocket;
  void (*processClient)(void * arg);  
  eventQueueNode *next;
  </code></pre>
  
  <p>};</p>
  
  <p>The main thread puts those events into the queue whenever a socket is ready for read. A worker picks it up from the queue, reads the request from the socket, and sends the reply. </p>
  
  <p>My very basic protocol for this communication is:</p>
  
  <p>The client sends to the server request of form:</p>
  
  <pre><code>FETCH some-data-name
  </code></pre>
  
  <p>Followed by two newlines to indicate the end of transmission. 
  The server replies with desired data, followed by 2 newlines as well. </p>
  
  <p>Right now all the processing of this request (reading it from socket, parsing, querying for data, sending the response) is handled by the worker thread. Is this a correct approach?</p>
  
  <p>What bothers me:</p>
  
  <p>Let's say there are 4 worker threads and 4 events from the same user in the queue. Workers pick the requests up and simultaneously read and write to the same socket. Is this resulting in dirty reads/writes? (e.g one thread gets a part of a client request, and the other thread the rest and thus generating no response to invalid requests). Should I use mutexes on those descriptors until I read a full request? Another idea is to read the request in the main thread and put the request itself into event queue. Then workers would then only need to write to the socket (do I still need a mutex here?).</p>