Flash calling Php calling Perl

B

Bill H

Background:

I have a flash program that posts user enter data to a php program on
the server.
The php program then saves this data in a database and then uses system
() to call the perl program which takes the data and generates a pdf
file and thumbnail images.
The php program, on completion of the perl program then sends a status
back to flash telling it was done. Flash then calls the php script to
get thes thumbnails for the view to see. This process can take 10 or
more seconds on the perl side to complete.

We are changing the flash aplication so that there is no need for it
to display the thumbnails after posting the data over and I am looking
for a way of having the php program just start the perl program but
not wait for it to complete before sending back the status to flash.

From all the possible PHP commands, exec(), shell_exec(), passthru()
and system(), it seems that they all wait for the called program to
finish, is there a way to just start the program and not wait for it
to complete?

The other method would be to send the results back to flash prior to
calling the perl program and not care how long perl took to do its
job. Would flush() and ob_flush() be sufficient to force this
information out to flash (the only information being sent back is
"result=saved" or "result=fail")?

If this is not possible, then on the perl side (crossposted to
comp.lang.perl.misc for this question), is there a way of having a
script take the command line arguments passed by php's shell() and
forking (is this right term?) the real perl program and ending so that
php is not waiting for the real program to finish?



Bill H
 
J

Jerry Stuckle

Bill said:
Background:

I have a flash program that posts user enter data to a php program on
the server.
The php program then saves this data in a database and then uses system
() to call the perl program which takes the data and generates a pdf
file and thumbnail images.
The php program, on completion of the perl program then sends a status
back to flash telling it was done. Flash then calls the php script to
get thes thumbnails for the view to see. This process can take 10 or
more seconds on the perl side to complete.

We are changing the flash aplication so that there is no need for it
to display the thumbnails after posting the data over and I am looking
for a way of having the php program just start the perl program but
not wait for it to complete before sending back the status to flash.

From all the possible PHP commands, exec(), shell_exec(), passthru()
and system(), it seems that they all wait for the called program to
finish, is there a way to just start the program and not wait for it
to complete?

http://www.lmgtfy.com/?q=php+exec+background

Lots of hits show how you run programs in the background from PHP. How
to do it is system specific, though, and you must redirect stdout.

For instance in Linux, you might do

exec("/usr/bin/perl /home/mydir/perlscript > /dev/null &");
The other method would be to send the results back to flash prior to
calling the perl program and not care how long perl took to do its
job. Would flush() and ob_flush() be sufficient to force this
information out to flash (the only information being sent back is
"result=saved" or "result=fail")?

Not reliably. flush() and ob_flush() clear the PHP buffers, but you
can't force the data to be sent from the web server. The only way to
ensure the data is sent is for the script to end.
If this is not possible, then on the perl side (crossposted to
comp.lang.perl.misc for this question), is there a way of having a
script take the command line arguments passed by php's shell() and
forking (is this right term?) the real perl program and ending so that
php is not waiting for the real program to finish?



Bill H


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
(e-mail address removed)
==================
 
C

ccc31807

The php program, on completion of the perl program then sends a status
back to flash telling it was done. Flash then calls the php script to
get thes thumbnails for the view to see. This process can take 10 or
more seconds on the perl side to complete.

Why are you using PHP if all PHP does is act as an intermediary to
accept input from Flash and emit output to Perl? Do you really need to
have insert and select queries from a database? Seems to me you would
have a cleaner and more stable app calling Perl directly and by-
passing PHP and the DB entirely to the extent that you perform a write
and read operation before you start creating your files.

get_data($user_supplied_data);
insert_data($connection_dbh, $user_supplied_data);
create_documents($user_supplied_data);
We are changing the flash aplication so that there is no need for it
to display the thumbnails after posting the data over and I am looking
for a way of having the php program just start the perl program but
not wait for it to complete before sending back the status to flash.

You implied that this would be suitable for a multi-threaded app but
didn't directly say so. If you have multiple cores and multiple tasks,
you might be able to decompose your tasks into different processes and
queue them to pass to any processor that can run the process. If you
have only one processor this probably wouldn't make much sense.
If this is not possible, then on the perl side (crossposted to
comp.lang.perl.misc for this question), is there a way of having a
script take the command line arguments passed by php's shell() and
forking (is this right term?) the real perl program and ending so that
php is not waiting for the real program to finish?

I have a couple of tasks that process several thousand files at a time
using data queried from a database, creating, printing, emailing, and
then deleting each file. My main Perl script calls helper scripts each
of which is designed to do exactly one thing. It's mostly a hack, but
it works (which is the main thing) and I don't have to wait until the
last file is handled to start using the earlier files.

CC
 
M

Mark Smith

Background:

I have a flash program that posts user enter data to a php program on
the server.
The php program then saves this data in a database and then uses system
() to call the perl program which takes the data and generates a pdf
file and thumbnail images.
The php program, on completion of the perl program then sends a status
back to flash telling it was done. Flash then calls the php script to
get thes thumbnails for the view to see. This process can take 10 or
more seconds on the perl side to complete.

We are changing the flash aplication so that there is no need for it
to display the thumbnails after posting the data over and I am looking
for a way of having the php program just start the perl program but
not wait for it to complete before sending back the status to flash.

From all the possible PHP commands, exec(), shell_exec(), passthru()
and system(), it seems that they all wait for the called program to
finish, is there a way to just start the program and not wait for it
to complete?

The other method would be to send the results back to flash prior to
calling the perl program and not care how long perl took to do its
job. Would flush() and ob_flush() be sufficient to force this
information out to flash (the only information being sent back is
"result=saved" or "result=fail")?

If this is not possible, then on the perl side (crossposted to
comp.lang.perl.misc for this question), is there a way of having a
script take the command line arguments passed by php's shell() and
forking (is this right term?) the real perl program and ending so that
php is not waiting for the real program to finish?

Bill H

If it was me, unless your perl script is doing something really
special I'd do it all in php:

http://www.fpdf.org/
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top