Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Closing stdout on CGI early.

by tomazos (Deacon)
on Aug 31, 2001 at 01:56 UTC ( #109218=perlquestion: print w/replies, xml ) Need Help??

tomazos has asked for the wisdom of the Perl Monks concerning the following question:

I have a CGI script that I want to add extra functionality to.

The extra functionality does not effect the output, so I want to close the output and then do it - so that the extra functionality does not hold up the web browser on the client machine.

How do I signify to apache that I am finished returning output from my script and close the output?

Will this actually speed up the process? Or is apache going to cache the output of my script and only return it once my script has finished executing anyway?

Replies are listed 'Best First'.
Re: Closing stdout on CGI early.
by dga (Hermit) on Aug 31, 2001 at 02:05 UTC

    If Apache requires your program to exit to close out the browser, one possibility would be to close STDOUT and fork() and have the child do the work and the parent can exit when its done with the output.

    If you ever move to mod_perl this will defeat the reduction in startup overhead since you will need to start a new script every time anyway. If it doesn't break mod_perl entirely by exiting early.

    For mornal CGI this may work ok for you.

    Update: Another thought. I have a system which needs some slowly changing data from another database so I have a daemon process that listens on a FIFO and my CGI script writes an information request to the FIFO and then goes on with its life.

    The daemon process then reads the FIFO and gets the updates independant from the web process completely. The FIFO is checked in non blocking mode by the CGI for obvious reasons and the update request is just skipped by the CGI if the FIFO isn't ready to read data for any reason.

    As a side benefit the web system can run 'offline' for a while completely transparent to the end users.

      My solution will be to use database - I am a database guy...;-)

      When you want another process to handle something, delegate: write in some table parameters of what needs to be done, and set status to 'Scheduled'. Then, "boss" process is done and can return.
      Later (nightly), you can run "subordinate" script via cron. It will read all task sheduled, try to process them (changing status to "In Process', and after completion, change status again, to 'OK' or 'Failure' (and saving status or sending email or something you need), and will exit when no more task are scheduled. I do not have expereince with Apache, if starting new process via cron is more expensive, or you need results to be processes ASAP, just leave "subordinate" running all the time.

      Later "boss" process can check status of tasks scheduled (you may sort them by userID or something), and even try to re-schedule rejected tasks (after fixing error).

      Database transactions will handle all record locking.

      Does it make sense? It plan to use something like that in my system later, not now (so no code right now, sorry).

      Can you monks with expertise in Apache tell me what is better method (less resorce hog) to run "subordinate": all the time (without need to start new process), sleeping some time, or via cron, requiring to start new process occasionally. I understand it is a trade-off, what will be the guidelines for right decision?

      To make errors is human. But to make million errors per second, you need a computer.

Re: Closing stdout on CGI early.
by shotgunefx (Parson) on Aug 31, 2001 at 02:27 UTC
    Had the same problem. See this node.


    "To be civilized is to deny one's nature."

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://109218]
Approved by root
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2022-06-30 04:52 GMT
Find Nodes?
    Voting Booth?
    My most frequent journeys are powered by:

    Results (97 votes). Check out past polls.