[Zope-dev] Handling of ECONNRESET socket error in asyncore.py

[Oliver Bleutgen]

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