On Wed, 2006-02-08 at 02:33 -0500, Steve Holden wrote: > Martin v. Löwis wrote: > > Tim Peters wrote: [...] > > What is the reason that people want to use threads when they can have > > poll/select-style message processing? Why does Zope require threads? > > IOW, why would anybody *want* a "threadsafe patch for asynchat"? > > > In case the processing of events needed to block? If I'm processing web > requests in an async* dispatch loop and a request needs the results of a > (probably lengthy) database query in order to generate its output, how > do I give the dispatcher control again to process the next asynchronous > network event? > > The usual answer is "process the request in a thread". That way the > dispatcher can spring to life for each event as quickly as needed.
I believe that Twisted does pretty much this with it's "deferred" stuff. It shoves slow stuff off for processing in a separate thread that re-syncs with the event loop when it's finished. In the case of Zope/ZEO I'm not entirely sure but I think what happened was medusa (asyncore/asynchat based stuff Zope2 was based on) didn't have this deferred handler support. When they found some of the stuff Zope was doing took a long time, they came up with an initially simpler but IMHO uglier solution of running multiple async loops in separate threads and using a front-end dispatcher to distribute connections to them. This way it wasn't too bad if an async loop stalled, because the other loops in other threads could continue to process stuff. If ZEO is still using this approach I think switching to a twisted style approach would be a good idea. However, I suspect this would be a very painful refactor... -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
