Interprocess Communication in C++

问题:

I have a simple c++ application that generates reports on the back end of my web app (simple LAMP setup). The problem is the back end loads a data file that takes about 1.5GB in memory. This won't scale very well if multiple users are running it simultaneously, so my thought is to split into several programs :

Program A is the main executable that is always running on the server, and always has the data loaded, and can actually run reports.

Program B is spawned from php, and makes a simple request to program A to get the info it needs, and returns the data.

So my questions are these: What is a good mechanism for B to ask A to do something? How should it work when A has nothing to do? I don't really want to be polling for tasks or otherwise spinning my tires.

回答1:

Use a named mutex/event, basically what this does is allows one thread (process A in your case) to sit there hanging out waiting. Then process B comes along, needing something done, and signals the mutex/event this wakes up process A, and you proceed.

If you are on Microsoft :

Mutex, Event

Ipc on linux works differently, but has the same capability:

Linux Stuff

Or alternatively, for the c++ portion you can use one of the boost IPC libraries, which are multi-platform. I'm not sure what PHP has available, but it will no doubt have something equivalent.

回答2:

Use TCP sockets running on localhost.

1. Make the C++ application a daemon.
2. The PHP front-end creates a persistent connection to the daemon. pfsockopen
3. When a request is made, the PHP sends a request to the daemon which then processes and sends it all back. PHP Sockets C++ Sockets

EDIT

Added some links for reference. I might have some really bad C code that uses sockets of interprocess communication somewhere, but nothing handy.

回答3:

IPC is easy on C++, just call the POSIX C API.

But what you're asking would be much better served by a queue manager. Make the background daemon wait for a message on the queue, and the frontend PHP just add there the specifications of the task it wants processed. Some queue managers allow the result of the task to be added to the same object, or you can define a new queue for the finish messages.

One of the best known high-performance queue manager is RabbitMQ. Another one very easy to use is MemcacheQ.

Or, you could just add a table to MySQL for tasks, the background process just queries periodically for unfinished ones. This works and can be very reliable (sometimes called Ghetto queues), but break down at high tasks/second.