This is dumb (don't do it!)
[1/5] from: hallvard:ystad:oops-as:no at: 27-Jan-2004 11:29
Hi
I realize that writing
close system/ports/output
to a console session is dumb. But why does it make rebol crash? Shouldn't it simply hang
or something?
Just curious.
HY
[2/5] from: greggirwin:mindspring at: 27-Jan-2004 10:24
Hi Hallvard,
HY> close system/ports/output
HY> ...why does it make rebol crash? Shouldn't it simply hang or
HY> something?
I think so. I'll log it as a bug for the View 1.3 project.
-- Gregg
[3/5] from: hallvard:ystad:oops-as:no at: 29-Jan-2004 23:50
OK, the reason I did this, is I wonder if I can have a CGI script close the connection
to user and then continue processing some data afterwards. So that the web user wouldn't
have to wait ages for the browser to tell him the page has finished loading when actually
it is.
The following CGI script didn't do the trick. Anyone got an idea?
HY
Script:
#!/usr/local/bin/rebol -cs
REBOL []
set-net [...]
print "Content-Type: text/html^/"
print [<html><body><p><pre>]
probe system/options/cgi
print reverse [</html></body></p></pre>]
close system/ports/output
wait 30 ; seconds
print "HEHE"
send [x--y--name] "done"
Dixit Gregg Irwin (18.24 27.01.2004):
[4/5] from: SunandaDH:aol at: 30-Jan-2004 12:29
Hi Hallvard,
> OK, the reason I did this, is I wonder if I can have a CGI script close the
> connection to user and then continue processing some data afterwards. So
that
> the web user wouldn't have to wait ages for the browser to tell him the
page
> has finished loading when actually it is.
>
> The following CGI script didn't do the trick. Anyone got an idea?
I tried to find a foolproof way of doing this for something we needed or
REBOL.org. I failed.
Part of the problem is that you can't control when the server sends the data.
If you only have a small amount of data (not enough to fill whatever is a
block transmitted across the Internet) that probably won't be until your CGI
quits.
I tried various cunning schemes, like explicitly setting a Content-length
header and then sending more data than that (to force a block transmit). They
didn't work.
In the end, in our case, as we only need to run some non-user background
stuff occasionally, I added some rudimentary code to check that the request is not
from a human being. So we only run the "background task" if the referrer is a
bot. I don't mind keeping them waiting a couple of seconds once in a while.
And the "background task" is self-limiting -- it'll stop after a couple of
seconds, whether it's finished or not.
The site is hit by bots hundreds of times a day -- so the background task
never has to wait long to resume.
This kludge works because the background processing we need to do is not
related to the current message -- it's the equivalent of an occasional recycle to
keep things current.
Of course, we have to check that the background task isn't already running
(if we get two bots that trigger it in the same second or so).
If you find a better solution, please let me know!
Sunanda.<
[5/5] from: hallvard:ystad:oops-as:no at: 3-Feb-2004 0:19
Dixit [SunandaDH--aol--com] (18.29 30.01.2004):
>Hi Hallvard,
>[...]
>I tried to find a foolproof way of doing this for something we needed or
>REBOL.org. I failed.
>[...]
>If you find a better solution, please let me know!
Well, I don't know if this will work, it's only an idea:
You keep two CGI scripts, C1 and C2. C1 redirects to C2 with a 302 HTTP header. Now if
C1 is unaffected by the browser suddenly giving up and passing on to somewhere else,
it may quietly do its background task without anyone waiting. What the other end user
will see is only what is written by C2. Does web servers somehow detect if requesting
browsers no longer listen? And if so, do they kill CGI child processes? I wouldn't believe
so.
Just a thought
HY