Twisted concurrency with Bruce Eckel.

May 3rd, 2008 § 5 comments

I saw this on the ‘tubes today: Con­cur­rency with Python, Twisted, and Flex by Bruce Eckel.

Ever since I read it, I’ve got­ten that tickle again to tackle twisted. He offers a pretty ele­gant solu­tion to the prob­lem of chunk­ing up the work and spread­ing it across CPUs.

The draw for me to his solu­tion is the asyn­chro­nous way in which the results are dispatched/captured (I’m going to be doing a lot of async work soon). It’s a pretty good mini-intro into the semi-unpenetrable fort of Twisted.

Per­son­ally, I would have prob­a­bly approached this using the pro­cess­ing mod­ule ala (note, I assumed access to Bruce’s methods):

?View Code PYTHON
1
2
3
4
5
6
7
8
9
10
11
12
13
14
from processing import Pool, TimeoutError
pool = Pool(detectCPUs())
 
# ... skipping building the worklist, in bruce's case it's $cores * steps
TASKS = [ step1, step2, step3 ]
 
results = [pool.apply_async(t for t in TASKS]
imap_it = pool.imap(TASKS)
imap_unordered_it = pool.imap_unordered(TASKS)
 
print 'Ordered results using pool.apply_async():'
for r in results:
    print '\t', r.get()
print

Note, of course — I lifted the above right from the doc­u­men­ta­tion exam­ples for the mod­ule. Yes — I know, it lacks the network-ability that Bruce’s twisted-based solu­tion has innately (which does make his solu­tion quite nice). You could do the same with the pro­cess­ing Client/Listeners in the­ory, but twisted is doing all of the con­nec­tion man­age­ment for him under the covers.

Dan­git Bruce gave me the twisted itch again.

And later I’ll do a more com­plete solu­tion with the pro­cess­ing mod­ule, and com­pare the speeds of both against one another. I pre­fer the single-module solu­tion over the twisted.* approach — but I can be swayed. :)

  • http://orestis.gr Orestis Markou

    Can you do grid-like (mul­ti­ple com­put­ers) coor­di­na­tion with pro­cess­ing? It seems like twisted offers a very ele­gant and sim­ple way to cre­ate small dae­mons that are coor­di­nated from a server.

  • jnoller

    Twisted does have that ben­e­fit — it also has the ben­e­fit of hid­ing the net­work magic from you. In both the twisted and pro­cess­ing case, you are going to need to have the server exec some­thing on the clients and clients run­ning a lis­tener for the object being passed to them.

    Pro­cess­ing has the con­cept of managers/listeners that do the same thing, the one big draw twisted does have is the reac­tor async model which allowed Bruce in this case, to keep the UI server running/listening for events while the solvers were dispatched.

  • http://orestis.gr Orestis Markou

    I spent the past few hours try­ing to make Bruce’s exam­ple a bit more man­age­able — I aim to write a short blog post describ­ing my lit­tle helper module.

    The thing I don’t like in the twisted async approach is the “spaghetti exe­cu­tion” model. When read­ing code, the pat­tern “search for call­Re­mote, hunt for the call­backs” is very tir­ing. I’m aim­ing to put all this infor­ma­tion to a big event dic­tio­nary, so instead of attach­ing call­backs, you lis­ten for event (which del­e­gate to the defined callbacks).

    Any­way, more soon (hope­fully) here: http://orestis.gr

  • greg­n­wosu

    I agree, it would be nice to make the twisted reac­tor pat­tern appear less pro­ce­dural and more functional

  • greg­n­wosu

    I agree, it would be nice to make the twisted reac­tor pat­tern appear less pro­ce­dural and more functional

What's this?

You are currently reading Twisted concurrency with Bruce Eckel. at jessenoller.com.

meta