title: Choosing a IPC solution for an event-driven application
body: <p>I am currently working on a rather large single-threaded, event-based,  application designed around epoll under Linux and comparable technologies under other platforms. Currently, whenever we wish two instances to communicate, they typically do it through sockets, whether they are running on the same machine or not. For performance reason, I'm envisioning the use of some form of IPC to speed-up same machine communication. Now, I need to decide of which IPC mechanism to use.</p>
  
  <p>The following factors are important to me:</p>
  
  <ul>
  <li>event-driven, without complete redesign -- if the IPC mechanism doesn't fit well with epoll, that's months of work lost for me</li>
  <li>fast -- if this mechanism is not faster than sockets, it's not worth the time implementing it</li>
  <li>flexible and (re)configurable during execution -- I believe that this rules out MPI &amp; al</li>
  <li>no multi-threading required.</li>
  </ul>
  
  <p>I'm willing to use different mechanisms for different platforms, as long as they all use the same paradigm. I'm also willing to get as deep as needed into C / C++ / Obj-C for platform-specific bindings.</p>
  
  <p>Any suggestion?</p>
  
  <p>Thanks.</p>