I have a perl routine that takes some html form variables that are
"POST"ed to it from a Flash app (works the same as a web page POST)
and when it is done it sends back a status to the Flash program using
a simple:
print "Content-type:text/plain\n\n";
print "status=complete";
exit;
which works fine. What I would like to do is send the above so that
the Flash app goes about its business but have the perl program
continue on doing some stuff that I don't want the user to have to
wait for the completion of. What I am looking for is a way to simulate
whatever perl does for the waiting user when it performs the exit
without exiting. Something like this:
print "Content-type:text/plain\n\n";
print "status=complete";
"some magical perl command to force the above to the user
and end connection without stopping program"
additional code that is executed
exit;
Any clues, perldocs -f, online docs would be appreciated.
Bill H
Perhaps things will already work when you append a "\n" to that
last line? It could happen that a line without a trailing new-
line gets stuck in some internal buffers and only gets send to
the parent process when your script exits and all open files are
closed after the buffers are flushed. Or do
$| = 1;
to make sure stdout is unbuffered.
> exit;
>
> which works fine. What I would like to do is send the above so that
> the Flash app goes about its business but have the perl program
> continue on doing some stuff that I don't want the user to have to
> wait for the completion of. What I am looking for is a way to simulate
> whatever perl does for the waiting user when it performs the exit
> without exiting. Something like this:
> print "Content-type:text/plain\n\n";
> print "status=complete";
> "some magical perl command to force the above to the user
> and end connection without stopping program"
>
> additional code that is executed
> exit;
If appending a newline to the last line of ouput or setting
auto-flushing for stdout doesn't do the job I guess it's only
in parts a Perl issue and involves also the behaviour of the
process that started the Perl script. The question is: is what
the process that started your script waiting for. Is it waiting
for the stdout of yor script to become closed or is it waiting
for your script to exit? That would seem to me the most likely
scenarios. Thus you could try to do what that process is waiting
for, i.e. in the first case close stdout (and perhaps stderr)
and in the second fork() (to get a new process) and exit in the
parent process. I would try something like this:
close STDIN;
close STDERR;
exit 0 if fork;
The first two lines close stdin and stderr, just to make sure
all buffers are flushed, and the last one ends the parent pro-
cess while creating a new process for continuing with whatever
you still may have to do. If that works you can try if leaving
out the fork() also works. (But note: that's from a UNIX per-
spective, I have no idea how things work under Windows..)
Regards, Jens
--
\ Jens Thoms Toerring ___ j...@toerring.de
\__________________________ http://toerring.de
Bill> print "Content-type:text/plain\n\n";
Ignoring the rest of your message, this is an invalid header. Please ensure
that you have a space after the colon. Sure, some browsers error-correct for
your mistake, but it's best to simply do it right, in case some new browser
doesn't perform the same error correction.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
Actually the Flash app isn't waiting for anything technically, just
the command in actionscript to post the values to the perl application
has a receive part thats stays active till somethign is received. If I
keep posting without any receiving back eventually you can end up with
a stack issue, so best practice is to send back the status=complete
(btw if you add a trailing \n then flash doesn't like it - go figure).
I also may end up using that status=complete for something else
(failure code, or information back to the application).
> close STDIN;
> close STDERR;
> exit 0 if fork;
>
> The first two lines close stdin and stderr, just to make sure
> all buffers are flushed, and the last one ends the parent pro-
> cess while creating a new process for continuing with whatever
> you still may have to do. If that works you can try if leaving
> out the fork() also works. (But note: that's from a UNIX per-
> spective, I have no idea how things work under Windows..)
>
If I do this, do any variables declared before the exit 0 if fork
still remain (I would think so)?
Bill H
You are right Randal, unfortunately Flash 9 likes its this way.
Bill H
> Actually the Flash app isn't waiting for anything technically, just
> the command in actionscript to post the values to the perl application
> has a receive part thats stays active till somethign is received. If I
> keep posting without any receiving back eventually you can end up with
> a stack issue, so best practice is to send back the status=complete
> (btw if you add a trailing \n then flash doesn't like it - go figure).
Ok, so what about setting stdout to auto-flush
$| = 1;
to make sure the reading application actually gets that line
(or closing at least stdout)?
> I also may end up using that status=complete for something else
> (failure code, or information back to the application).
> > close STDIN;
Sorry, that should have been
close STDOUT;
> > close STDERR;
> > exit 0 if fork;
> If I do this, do any variables declared before the exit 0 if fork
> still remain (I would think so)?
Yes, you get a nearly exact copy of the parent process with
all variables intact. In most cases the only noticable dif-
ference is the return value of fork().
Bill> print "Content-type:text/plain\n\n";You are right Randal, unfortunately Flash 9 likes its this way.
Ignoring the rest of your message, this is an invalid header. Please ensure that you have a space after the colon. Sure, some browsers error-correct for your mistake, but it's best to simply do it right, in case some new browser doesn't perform the same error correction.