[Twisted-Python] A resizable cooperator class for queuing and dispatching jobs

Terry Jones terry at jon.es
Wed Dec 9 16:44:58 EST 2009


>>>>> "Glyph" == Glyph Lefkowitz <glyph at twistedmatrix.com> writes:
Glyph> On Dec 8, 2009, at 11:09 PM, Terry Jones wrote:
>> I just wrote a fun class that lets you
>> 
>> - submit jobs to be dispatched to a queue
>> - manage how many tasks are in progress at once
>> - dynamically adjust that number
>> - shut down cleanly, including
>> - recovering jobs that were queued but hadn't been dispatched

Glyph> That does sound like fun!

It *is* fun.

>> # Later... send off some SMS messages.
>> dispatcher.put((2127399921, 'Hello...'))
>> dispatcher.put((5052929919, 'Test...'))

Glyph> Not that this is really germane to the class in question, but, if
Glyph> you're going to be sending SMS messages

That was just an example. I even thought about using strings, but kept it
looking simpler.

>> # Later, bump up to 10 simultaneous jobs.
>> dispatcher.width = 10
>> 
>> # Oops, turns out we're sending too fast, turn it down a little.
>> dispatcher.narrow(3)

Glyph> This seems somewhat asymmetric.  Why are there 'widen' and 'narrow'
Glyph> methods if I can just set the 'width' attribute directly?  I could
Glyph> always just do '.width +=' and '.width -=' if I have a relative
Glyph> value.

Agreed. I started out just implementing widen and narrow, and they (barely)
survived when I later added the width property. I had been thinking it
would be good to just be able to change the width up or down a notch, but
then when I went to write my (a posteriori) tests, I realized that wasn't
really so convenient. So I think you're right they could be simplified
away.

But the code Glyph, the code? Or have I graduated to the point where I no
longer need a laconic garotting?  I think the combo of a DeferredQueue and
a task.Cooperator is pretty deadly.

Terry



More information about the Twisted-Python mailing list