Chris McDonough wrote:
AFAIK, there is no way to "kill" a thread. On top of that, there is no way to know if a browser "stop" actually means "stop processing" (for example in the case of a long-running method, a browser stop might just mean "I went to another web page, I'll be back, continue running").
Hmm, how should the browser come back? Where to? The TCP-connection is closed. You have no way to get data back to the browser. Press the stop button, tear the network out of the wall, the thread won't stop. Maybe you say that someone may want to start a long running job per browser request, like report creation or mass mailing, but who on his right mind would implement something that way? This has the small disadvantage of scaling exactly to 4 jobs in stock zope, AFAIK. Everyone would spawn an external process/thread, not (ab)use zope threads. An already highly loaded server has much more problems this way, because it doesn't profit from users pressing the stop button. Imagine you have one slow/hanging page, maybe representing data from an overloaded sql-database connected to zope. As it is now, sooner or later all of zope's worker threads will end up hanging there, making the site inaccessible, while the users who requested the offending pages have shut down their clients long ago. Yes, I know, there may some other timeouts kick in, but the principle still stands. Apache + mod_perl don't do that, btw, and I bet a lot of other servers don't do also. cheers, oliver