I am trying to build a simulation server which can be driven over the internet. Each simulation runs in its own process. The user should be able to start a simulation, stop a simulation, and get the status of a simulation by calling a PHP script over the internet. The simulations can take a very long time, and the "start simulation" call should not block. The "status" of the simulation is printed to stdout by the simulator so this needs to be made available to the user.
My initial design was to fork & exec the simulation, and pipe the results to a file. Then lookup the file when the user asks for the status. However, you cannot fork & exec in php inside an apache module. Should I use a dedicated application server? It seems a bit difficult to use a standard web server since there is no global state which stores the list of running processes (simulations).
Process Manager
Moderator: General Moderators
Re: Process Manager
The simulator is written in c++, but It should be modified as little as possible. I prefer to write a wrapper for it and exec the simulator and capture its stdout and make that accessible to the user.
Basically, the wrapper should have an web-accessible API with 3 commands.
1.) start_simulation - which basically forks & execs an instance of the simulator, recording its pid in a table, and piping its stdout to a known buffer. The wrapper should not allow more than 16 instances of the simulator to run on the server. If successful, it returns a simulation code to the user. Otherwise, it returns an error code.
2.) stop simuation - takes the simulation code returned in (1), and kills the associated process.
3.) get_process - takes the simulation code returned in (1), looks up the known buffer which holds the stdout for that process, and returns that information to the user.
Basically, the wrapper should have an web-accessible API with 3 commands.
1.) start_simulation - which basically forks & execs an instance of the simulator, recording its pid in a table, and piping its stdout to a known buffer. The wrapper should not allow more than 16 instances of the simulator to run on the server. If successful, it returns a simulation code to the user. Otherwise, it returns an error code.
2.) stop simuation - takes the simulation code returned in (1), and kills the associated process.
3.) get_process - takes the simulation code returned in (1), looks up the known buffer which holds the stdout for that process, and returns that information to the user.