Re: Embedding PHP in C

From: Date: Wed, 29 Aug 2001 12:35:13 +0000
Subject: Re: Embedding PHP in C
References: 1  Groups: php.general php.windows 
Request: Send a blank email to php-general+get-65005@lists.php.net to get a copy of this message
On Tue, 28 Aug 2001 11:19:01 -0500, cdudec@hotmail.com (Chris Wilson) wrote: >I'm doing a project for which I want to have a C/C++ act as a process proxy >for which can pass information and retrieve information from a called PHP >script. I think that can be done in perl however perl I don't take is the >best langauge. I've fell in love with PHP and would love use it and avoid >have to call PHP from the commandline and parsing the outputs. > >Any suggestion on if this can be done or any other langauge that do the >trick besides PERL.. i can think of several: 1. write an extension. it'd probably have to be C though, or you'd have to figure out the name-mangling if you wanted C++ in there. *while this is powerful, i would avoid it, myself because i prefer to work in C++ and the linking problems would take too much effort and time to deal with. 2. use pipes (popen) on the C/C++ process. A. this is an easy way to do things if the C/C++ thing is a one-shot deal (set command line params, read answer in stdout or return value). B. it's also a reasonable solution if you have half-duplex pipes and you only need to send data once (on command line) and read many lines of answer (use read mode, so "r"). or you need to send a lot of data to the program and you only need it to return a status code (use "w" mode and encode reply in return value from main(...)). C. this can be a general solution if your system supports full-duplex pipes (popen mode is "rw") since you can then set up as much interactivity as you want between PHP and your external program. using pipes and exec can be expensive. think about usage patterns before committing to this approach. it's a nice thing for quick and dirty solutions though. 3. write an application server. there are two types, both types have some common features. in general, you ask the application server to perform a service for you, you give it parameters, and it returns the answer. A. socket based server. the server sits on a socket, PHP opens connections to that socket and the server returns the answer back through the socket. B. exec or CGI based server. if the server is an external program that conforms to CGI, it could just be invoked via something like fopen("http://....","r"); you pass it parameters through GET (urlencoded on the command line) and you read lines from the program. a socket based server (either fork-style, like apache, or using select so single-daemon style, or perhaps using threads, on OSs that support them) is probably the least CPU intensive, but it's also harder to write. i've done all of the above, but with another language and C/C++, not PHP. with PHP i've used the popen thing with good success (it's the most convenient solution), but you really need to think about usage patterns there because spawning off processes like that is expensive and will affect server responsiveness when you start getting a lot of hits. my applications were only hit once every 15 to 30 minutes or so, so efficiency of resource use wasn't a big deal :). hth, tiger

« previous php.general (#65005) next »