title: How to signal select() to return immediately?
body: <p>I have a worker thread that is listening to a TCP socket for incoming traffic, and buffering the received data for the main thread to access (let's call this socket <em>A</em>). However, the worker thread also has to do some regular operations (say, once per second), even if there is no data coming in. Therefore, I use <code>select()</code> with a timeout, so that I don't need to keep polling. (Note that calling <code>receive()</code> on a non-blocking socket and then sleeping for a second is not good: the incoming data should be immediately available for the main thread, even though the main thread might not always be able to process it right away, hence the need for buffering.)</p>
  
  <p>Now, I also need to be able to signal the worker thread to do some other stuff immediately; from the main thread, I need to make the worker thread's <code>select()</code> return right away. For now, I have solved this as follows (approach basically adopted from <a href="http://mail.python.org/pipermail/python-list/2002-May/147063.html" rel="noreferrer">here</a> and <a href="http://www.developerweb.net/forum/showthread.php?t=5154" rel="noreferrer">here</a>):</p>
  
  <p>At program startup, the worker thread creates for this purpose an additional socket of the datagram (UDP) type, and binds it to some random port (let's call this socket <em>B</em>). Likewise, the main thread creates a datagram socket for sending. In its call to <code>select()</code>, the worker thread now lists both <em>A</em> and <em>B</em> in the <code>fd_set</code>. When the main thread needs to signal, it <code>sendto()</code>'s a couple of bytes to the corresponding port on <code>localhost</code>. Back in the worker thread, if <em>B</em> remains in the <code>fd_set</code> after <code>select()</code> returns, then <code>recvfrom()</code> is called and the bytes received are simply ignored.</p>
  
  <p>This seems to work very well, but I can't say I like the solution, mainly as it requires binding an extra port for <em>B</em>, and also because it adds several additional socket API calls which may fail I guess – and I don't really feel like figuring out the appropriate action for each of the cases.</p>
  
  <p>I think ideally, I would like to call some function which takes <em>A</em> as input, and does nothing except makes <code>select()</code> return right away. However, I don't know such a function. (I guess I could for example <code>shutdown()</code> the socket, but the side effects are not really acceptable :)</p>
  
  <p>If this is not possible, the second best option would be creating a <em>B</em> which is much dummier than a real UDP socket, and doesn't really require allocating any limited resources (beyond a reasonable amount of memory). I guess <a href="http://en.wikipedia.org/wiki/Unix_domain_sockets" rel="noreferrer">Unix domain sockets</a> would do exactly this, but: the solution should not be much less cross-platform than what I currently have, though some moderate amount of <code>#ifdef</code> stuff is fine. (I am targeting mainly for Windows and Linux – and writing C++ by the way.)</p>
  
  <p>Please don't suggest refactoring to get rid of the two separate threads. This design is necessary because the main thread may be blocked for extended periods (e.g., doing some intensive computation – and I can't start periodically calling <code>receive()</code> from the innermost loop of calculation), and in the meanwhile, someone needs to buffer the incoming data (and due to reasons beyond what I can control, it cannot be the sender).</p>
  
  <p>Now that I was writing this, I realized that someone is definitely going to reply simply "<a href="http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio.html" rel="noreferrer">Boost.Asio</a>", so I just had my first look at it... Couldn't find an obvious solution, though. Do note that I also cannot (easily) affect how socket <em>A</em> is created, but I should be able to let other objects wrap it, if necessary.</p>