Hello all,
Thanks for the reply Gerald. FYI I am doing this under 2.0
Well a came up with a working solution, but since this is the first time
doing this I am not sure that what I have done it in the cleanest
manner. Here is what I did:
I stored my parameters into a Storable format file and create a random
number + .pld as the file name in a tmp directory.
I attempted to use the freeze/thaw method outlined in the guide, but I
couldn't get the correct results, even my attempts outside of the
mod_perl environment didn't yield what I thought it would, but that is
for another day.
I used Proc::Fork's child function to call my external script and pass
the file name as an argument. Before the call to the external script I
call set $SIG{CHLD} = 'IGNORE';
Inside my external script I read in the Storable file and execute
accordingly.
Prior to spawning the child process I return my page content to the
server which includes a meta refresh command, while waiting for the
refresh I use a timed DHTML script to display messages about what is
(should) be occuring in the background.
This is all the spawning of the process boiled down to:
use Proc::Fork;
$SIG{'CHLD'} = 'IGNORE';
child {
exec( $app, $file_number ) or warn "Can't run $app $!" );
}; # this closes the child block and the ; is needed.
On the html page that is sent I use a simple JavaScript:
<form name="form1">
<input type="text" name="input1" size="50">
</form>
<script language="javascript" type="text/javascript">
messages = new Array($js_array);
times = new Array($time_array);
var counter = 0;
function phrase()
{
document.form1.input1.value = " " + messages[counter];
counter++
setTimeout("phrase();",times[counter]);
}
phrase();
</script>
The $js_array and $time_array are the messages and the length of time to
delay between each call. And the meta tag refresh handles the actual
final redirect to the same page. I am caching the results so if there
is a "fresh" copy I just run the code that displays the results if not
calls the above sequence again.
By the way I haven't come across anything "odd" in Embperl 2.07 while
working with it. I have it installed and running on FreeBSD, Linux
RedHat 7.1 and Mandrake 8.1 (Perl 5.5.3, 5.6.0, and 5.6.1 respectfully)
along with the latest Apache and mod_perl. I have only toyed with it in
Windows. The biggest thing I noticed that wasn't "obvious" to *me* was
that in the configuration it is now Embperl::Object instead of
EmbperlObject, that gave me some difficultly while attempting to get up
and running when switching from 1.3.x , but then maybe I am just in too
much of a hurry at the time :)
Aaron Johnson
On Sun, 2002-05-19 at 11:05, Aaron Johnson wrote:
> Hello all,
>
> I have a page that takes a considerable amount of time to run and then
> return results to the browser, I am caching the information so
> subsequent requests return the results much quicker. My question is two
> fold:
>
> 1. How can I allow the browser to display something while the process is
> running to let the user know the server is working and prevent a timeout
> in by the browser. (interim page)
>
> 2. I need the above method/technique to be overridden when dealing with
> cached results.
>
> My idea to date is writing the Embperl data (%fdat,%udat) to disk and
> then passing the temp filename to a spawned (detached) process, but I am
> not even 100% sure how do that since I am not sure at what stage of the
> processing I am allowed to spawn a process and still return content to
> the browser.
>
> At the very least I would like to know what this is called as far as the
> page transaction process goes under mod_perl so I can better understand
> what some other options might be.
>
> Aaron Johnson
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
