Re: close STDOUT does not work, why?

Try closing STDIN and STDERR also.

It's probably dependant upon the webserver you are using, but the one I'm playing with doesn't seem to let go of the perl script and send the html until all three shared handles are closed. YMMV with other webservers, but it's worth a shot.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Comment on Re: close STDOUT does not work, why?

Replies are listed 'Best First'.
Re^2: close STDOUT does not work, why? by Anonymous Monk on Aug 25, 2007 at 04:37 UTC
Yep, that did the trick. Thanks a lot BrowserUk.	[reply]
Re^2: close STDOUT does not work, why? by Anonymous Monk on Sep 04, 2008 at 19:42 UTC
Ditto! :) Thanks.	[reply]
Re^2: close STDOUT does not work, why? by Anonymous Monk on Aug 25, 2007 at 04:38 UTC
Yep, that did the trick. Thanks a lot BrowserUk. Now if I can get my server push to work correctly.	[reply]
Re^3: close STDOUT does not work, why? by BrowserUk (Patriarch) on Aug 25, 2007 at 05:19 UTC
Now if I can get my server push to work correctly. Sorry, I can't help you there. I don't see how the script can continue to send 'multipart/x-mixed-replace' content after it has closed the handles to get the webserver to let go? Thinking about it, I guess it might be possible to fool the webserver by duping STDOUT etc. before closing the originals. I haven't tried that, it just came to me. I've been playing around with client pull for long running processes and found that the best way (on Win32) was to open a new socket, start a new process that inherits the open handles, redirect the browser to that new socket and have the original cgi script terminate. The spawned process then runs as a very limited html daemon responding to client pull requests on a thread with updated status information until the long running process has finished. I can then deliver the final status/output and die. The thing I like about this is that it removes the client pull from the webserver, and also allows the long running process to detect if the client goes away, and terminate early if it does. But take all that with a huge handful (bucketful) of salt because literally all I've done is play with it. I've never tried using it for real. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice. "Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."	[reply]