Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > CGI script: release browser after spawning new process

Reply
Thread Tools

CGI script: release browser after spawning new process

 
 
Prachi
Guest
Posts: n/a
 
      05-17-2005
The purpose of this cgi script is to receive cgi parameters from a user
filled form and pass them along as command line parameters to another
perl script that should run the computation in the background. I used
perl exec because it spawns this new process and does not return.

-----
my $command = 'perl RunComputation.cgi ';
foreach my $cgi_param ($q->param) {
if ($q->param($cgi_param) && $q->param($cgi_param) ne ' ') {
if($cgi_param =~ /check\d+/) {
my @vals = $q->param($cgi_param);
foreach my $v (@vals) {
$command .= $cgi_param.'="'.$v.'" ';
}
} else {
$command .= $cgi_param.'="'.$q->param($cgi_param).'"
';
}
}
}
exec $command;
-----

The new process spawns well and the scripts behave as excepted, except
that while this child process is executing the browser stays active and
keeps loading. I want to release the browser (or provide an explicit
end of cgi command, whatever is possible) as soon as this background
process starts.
Is that possible?

Thanks,
Prachi.

 
Reply With Quote
 
 
 
 
Prachi
Guest
Posts: n/a
 
      05-17-2005
Sorry folks. Maybe this is a wrong list post this. I sent it to
comp.infosystems.www.authoring.cgi

Thanks,
Prachi

 
Reply With Quote
 
 
 
 
Prachi
Guest
Posts: n/a
 
      05-17-2005
Well, the background process sends the user an email when the process
completes, so I do not need to notify the client.
Here's how I would like it to be:
1. The foreground process prints a notice that the request has been
submitted and run in background and an email will be sent when
completed.
2. end of HTML and HTTP
3. Spawn the background process
4. release from the browser
5. Run the background and send email when finished.

Thanks,
Prachi

 
Reply With Quote
 
Christopher Nehren
Guest
Posts: n/a
 
      05-17-2005
On 2005-05-17, Prachi scribbled these
curious markings:
> Well, the background process sends the user an email when the process
> completes, so I do not need to notify the client.
> Here's how I would like it to be:
> 1. The foreground process prints a notice that the request has been
> submitted and run in background and an email will be sent when
> completed.
> 2. end of HTML and HTTP
> 3. Spawn the background process
> 4. release from the browser
> 5. Run the background and send email when finished.


Can you perhaps write a background process that runs constantly, and
that then accepts input from your CGI program? For example, on a Unix
system, you could create a Unix socket with a daemon and then write to
the socket with the CGI application. The background program then churns
away and does its magic -- all the while, your CGI program, having
completed its work, can return a response to the browser pretty much
immediately. This has the added advantage of not having to wait for two
process creations (one is the perl process to handle the CGI itself and
the second is for the background process) per page view. If you move to
mod_perl, you have zero process creations.

Of course, Unix sockets aren't portable. Probably the most portable way
to accomplish this would be to start a simple TCP server on the machine.

Best Regards,
Christopher Nehren
--
I abhor a system designed for the "user", if that word is a coded
pejorative meaning "stupid and unsophisticated". -- Ken Thompson
If you ask the wrong questions, you get answers like "42" and "God".
Unix is user friendly. However, it isn't idiot friendly.
 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      05-17-2005
"Prachi" <(E-Mail Removed)> wrote:
> The purpose of this cgi script is to receive cgi parameters from a user
> filled form and pass them along as command line parameters to another
> perl script that should run the computation in the background. I used
> perl exec because it spawns this new process and does not return.
>
> -----
> my $command = 'perl RunComputation.cgi ';
> foreach my $cgi_param ($q->param) {
> if ($q->param($cgi_param) && $q->param($cgi_param) ne ' ') {
> if($cgi_param =~ /check\d+/) {
> my @vals = $q->param($cgi_param);
> foreach my $v (@vals) {
> $command .= $cgi_param.'="'.$v.'" ';
> }
> } else {
> $command .= $cgi_param.'="'.$q->param($cgi_param).'"
> ';
> }
> }
> }
> exec $command;
> -----
>
> The new process spawns well and the scripts behave as excepted, except
> that while this child process is executing the browser stays active and
> keeps loading.


You haven't spawned a new process, you have transformed into a different
program (but still the same "process" from unix's perspective).
You have to close STDOUT and STDERR, that way the server knows
the process is done talking to it. However, common servers will
kill the cgi process once they are done with it, so your process may
get killed early. You need a fork to protect from this.


> I want to release the browser (or provide an explicit
> end of cgi command, whatever is possible) as soon as this background
> process starts.
> Is that possible?


fork, and then the parent should exit normally, and the child
should close (or reopen) STDOUT and STDERR and then exec (or just proceed
to do whatever needs doing by itself).

fork and exit;
open STDERR, ">>log/whatever";
close STDOUT;
#do whatever needs to be done;

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
Jim Gibson
Guest
Posts: n/a
 
      05-18-2005

Prachi wrote:
> Well, the background process sends the user an email when the process
> completes, so I do not need to notify the client.
> Here's how I would like it to be:
> 1. The foreground process prints a notice that the request has been
> submitted and run in background and an email will be sent when
> completed.
> 2. end of HTML and HTTP
> 3. Spawn the background process
> 4. release from the browser
> 5. Run the background and send email when finished.
>
> Thanks,
> Prachi


Please include a little context in your replies. As a Google Groups
user, you should be aware that many if not most of the people reading
your posts do not use Google. Most newsreaders do not show all of the
posts in a thread the way Google does. Therefore, you need to include
the relevant parts of the posts to which you are responding. The best
way to do this is to eschew the 'Reply' link below each message and
click on the 'Show options' link instead. Then select the 'Reply' link
in the options box that appears. This will include the full content of
the previous post as quoted text by preceding each line with '> '.
Delete the portions of the previous post that are not relevant. Also,
you may intersperse your comments in the quoted text, as the quote
characters will show which text is yours and which is not.

If you don't follow these guidelines, you will reduce the probability
of getting good answers. Many of the most knowledgable Perl experts
here have stopped reading posts from Google users because they too
often violate the guidelines for this group. You should consider using
another source for Usenet groups and using a real newsreader that does
not have these problems.

Thanks.

 
Reply With Quote
 
NeilS
Guest
Posts: n/a
 
      05-18-2005
<(E-Mail Removed)> wrote in message
news:20050517163658.101$(E-Mail Removed)...
> "Prachi" <(E-Mail Removed)> wrote:
>> The purpose of this cgi script is to receive cgi parameters from a user
>> filled form and pass them along as command line parameters to another
>> perl script that should run the computation in the background. I used
>> perl exec because it spawns this new process and does not return.
>>
>> -----
>> my $command = 'perl RunComputation.cgi ';
>> foreach my $cgi_param ($q->param) {
>> if ($q->param($cgi_param) && $q->param($cgi_param) ne ' ') {
>> if($cgi_param =~ /check\d+/) {
>> my @vals = $q->param($cgi_param);
>> foreach my $v (@vals) {
>> $command .= $cgi_param.'="'.$v.'" ';
>> }
>> } else {
>> $command .= $cgi_param.'="'.$q->param($cgi_param).'"
>> ';
>> }
>> }
>> }
>> exec $command;
>> -----
>>
>> The new process spawns well and the scripts behave as excepted, except
>> that while this child process is executing the browser stays active and
>> keeps loading.

>
> You haven't spawned a new process, you have transformed into a different
> program (but still the same "process" from unix's perspective).
> You have to close STDOUT and STDERR, that way the server knows
> the process is done talking to it. However, common servers will
> kill the cgi process once they are done with it, so your process may
> get killed early. You need a fork to protect from this.
>
>
>> I want to release the browser (or provide an explicit
>> end of cgi command, whatever is possible) as soon as this background
>> process starts.
>> Is that possible?

>
> fork, and then the parent should exit normally, and the child
> should close (or reopen) STDOUT and STDERR and then exec (or just proceed
> to do whatever needs doing by itself).
>
> fork and exit;
> open STDERR, ">>log/whatever";
> close STDOUT;
> #do whatever needs to be done;


Yup, beat me to it! I haven't got time to play with it now but what about a
system call, that 's based on a fork with nested exec as I recall. If I'm
wrong feel free to flame me!


 
Reply With Quote
 
xhoster@gmail.com
Guest
Posts: n/a
 
      05-18-2005
"NeilS" <(E-Mail Removed)> wrote:
> >
> > fork, and then the parent should exit normally, and the child
> > should close (or reopen) STDOUT and STDERR and then exec (or just
> > proceed to do whatever needs doing by itself).
> >
> > fork and exit;
> > open STDERR, ">>log/whatever";
> > close STDOUT;
> > #do whatever needs to be done;

>
> Yup, beat me to it! I haven't got time to play with it now but what about
> a system call, that 's based on a fork with nested exec as I recall. If
> I'm wrong feel free to flame me!


There are some (potential) problems with just using system.

If the parent doesn't close STDERR and STDOUT until after the "system"
then it doesn't release the browser, so there is no point in doing it that
way (unless it puts child in background).

If the parent closes STDERR and STDOUT before calling system, then there is
a chance that Apache will clobber the parent after the "close"s but before
the "system", and therefore "system" never gets called. If the parent does
make it to the "system" before getting clobbered, I don't know what will
happen when it does get clobbered. Sometimes it seems like a child also
dies if it is still associated with the parent when the parent gets
clobbered.

If you system to put the child in the background (system "foo.pl&" on
unix), and then closes STDOUT and STDERR after that, that is probably
immune from both of the above paragraphs.

Xho

--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Spawning a new UI process Ed Leafe Python 0 11-09-2008 02:24 AM
How to force new Session when spawning browser using hyperlink BÝrge Hansen ASP .Net 4 09-02-2007 02:22 PM
Spawning a process with ASP.NET 2.0 beta 2 Marianne ASP .Net 4 07-07-2005 11:09 AM
Apache CGI and spawning another process Francis Hwang Ruby 2 05-09-2005 09:17 AM
Error Spawning Process from ASP.NET hoochiegooch@hotmail.com ASP .Net 4 02-08-2005 04:37 PM



Advertisments