[Twisted-Python] module interface checking tool

Dave Peticolas dave at krondo.com
Mon Aug 9 23:16:50 MDT 2004

On Mon, 2004-08-09 at 22:03, Dave Peticolas wrote:
> On Mon, 2004-08-09 at 21:23, Glyph Lefkowitz wrote:
> > On Mon, 2004-08-09 at 22:48, Dave Peticolas wrote:
> > 
> > > On the subject of adbapi using t.i.threads._putResultInDeferred,
> > > the latter function is useful for anyone managing their own threads.
> > > Anyone object if it is renamed to putResultInDeferred and made
> > > public?
> > 
> > Actually, yes, I would object.
> > 
> > It's a severe wart that adbapi uses t.p.threadpool directly; IIRC it's
> > one of the major issues with doing a proper reactor shut-down.  It
> > should be doing reactor.callInThread, not its own thread management.  I
> > will note that the API which uses it is simply a deferToThread clone.
> > 
> > All the thread-management logic in adbapi can easily be ported to use
> > t.i.threads.deferToThread and use logical task queue identifiers instead
> > of physical thread IDs.  If you agree, please create an issue in the
> > tracker for this.
> I agree, with the caveat that the reactor threadpool size
> adjustment api will need to be enhanced so that adbapi can
> request more threads if the max connections is high, without
> reducing threads if the max is low. suggestThreadPoolSize
> is too crude to do that. Min threads probably needs to be
> adjustable as well. Agreed?

On further thought, I'm not so sure about this. I have a real
application that is managing multiple connection pools. If
every connection pool is sharing the same threadpool, how
can I prevent one connection pool from starving the others,
as well as non-adbapi tasks?


More information about the Twisted-Python mailing list