5

I have a PHP web application that needs to call a function in a C++ library. This library is provided by a vendor (libfoo.a on a linux machine).

  1. My first instinct is to create a C++ executable that links against libfoo.a, and passes command-line parameters to the function. The PHP web application can then do a system() call to my c++ executable. This would be easy to implement. My concern is whether it would add a lot of overhead to create a new system process for each call. How much would this overhead be?

  2. An alternative is that I could use SWIG to wrap the C++ function in a PHP extension, but I don't have the C++ source code. Does SWIG support linking with a ".a" library? Would it require every other engineer on my team to change their PHP configuration to build in libfoo.a?

If the overhead of the system() call is small (< 30 ms), I would prefer option #1, as it seems much simpler to create the C++ executable once, and not build it into the PHP application. What are your recommendations on the two options?

eggplant
  • 155
  • 2
  • 8
  • do u require output from `C++` ? if not u can consider push the call to background - http://stackoverflow.com/questions/45953/php-execute-a-background-process – ajreal Nov 11 '10 at 20:11
  • just a simple outside observation, but without knowing how often it will be called, it sounds like you'd be better off making a C++ executable (which would allow for use outside of PHP as a bonus). If you made it into a PHP extension, I imagine you'd inevitably face the nightmare of distribution and compatibility upkeep even for just a small, private user base. Have you tried or discovered anything since you opened this question? – bob-the-destroyer Apr 05 '11 at 22:29

4 Answers4

2

keep in mind that C++ vs C produces different function name mangling thus different DLL function names with the same-looking functions which means different linkage.

"Third party extension providers must rebuild their extensions to make them compatible and loadable with the Visual Studio C++9 builds that we now provide."

Jim Michaels
  • 669
  • 5
  • 9
1

I would suggest using some IPC (inter process communication) protocol. If you are gonna write the C++ application using the library anyway - write some communication protocol (using TCP/IP or unix sockets) and start the application as a daemon

see man 3 daemon, man 2 fork and Unix sockets guide

P.S. building the library into PHP is not a good idea - C++ is not that failsafe like PHP. if the library or php module crashes - the whole webserver crashes or in the best scenario the one server process crashes. If you separate it and the program/lib crashes, you can show message that something is wrong (or even send alert email), which can't happen if your web server is down

NickSoft
  • 3,215
  • 5
  • 27
  • 48
0

I would recommend option 2. I do not have experience with PHP/SWIG but have done the same thing for perl, java, and PLSQL (oracle). We'll code some core functionality in a bit of C/C++ (and use 3rd party libraires) which we then wrap in an appropriate wrapper.

We do this mainly so we don't have duplicate the core functionality in the three application languages. The efficiency of using C is an added benefit. And Using a wrapper like this is (in my opinion) safer than than "shelling out" with system because you can pass proper parameters and return values as variables opposed to the messy business of parsing standard output.

Main points to remember:

  • You will need to use some function provided by application language (PHP for you) to allocate any memory for new data. e.g. in perl its NewSV.
  • There is usually some config required to tell PHP where to find your compiled .so/.dll
Sodved
  • 8,428
  • 2
  • 31
  • 43
0

Not sure what you did finally but I've done a simple php wrapper extension years ago calling a C++ lib. Like this you will not have overhead of a system call. I'ts not an issue for you, but you'll have finer control over calls to the lib. For example keeping the wrapper loaded in memory as opposed to loading it on each call, keeping custom configuration parameters etc. I depends on the nature of your lib.

Just some references that might be of interest:

Community
  • 1
  • 1
Derick Schoonbee
  • 2,971
  • 1
  • 23
  • 39