It would be nice if [ns_conn isconnected] did that, and there was another routine [ns_conn isconn] to tell whether this thread is associated with a connection at all (like the current isconnected does). We usually just do [ns_conn blah] inside a catch to handle the case of calling it from a scheduled proc or detached thread, rather than calling [ns_conn isconnected].
I wouldn't want a thread to just abort spontaneously when the connection died. That could leave things in a bad state. But being able to poll for it at convenient points would be nice, for example, inside a report generation loop. What happens when someone double-clicks a link using a persistent (keepalive) connection? Does the browser send both requests down the same connection? Jim > In AOLserver 3.x (and 3.3+ad13 in particular), I believe that a > connection thread continues to execute until it eiter finishes all the > code it's running or errors out. The thread never "knows" that the > client is no longer waiting for a request, and so can never try to > stop running because of that. And, nothing else ever prevents a > thread from running to completion. > > Is that true? Is it going to remain true for AOLserver 4.x? > > And if you do want to detect whether the client is still waiting (aka, > the client tcp/ip connection is still live?), is there any way to do > that? (I think this was discussed here before, but I couldn't seem to > find it in the archives.) > > Thanks! > > -- > Andrew Piskorski <[EMAIL PROTECTED]> > http://www.piskorski.com >
