views:

29

answers:

2

I'm working with an application that needs to be make some time consuming SOAP requests (using suds, as it were). There are several instances where a user will change the state of an object and in doing so trigger one or more SOAP requests that fetch some data. This could be done in the background, and right now the user has to wait while these finish.

Is this a reasonable use case for Python threads? Or is that just asking for trouble? Better suggestions?

+1  A: 

That sounds great! You almost always want to do long running stuff in a background thread, and many soap requests spend a lot of time waiting on network IO...

The only question is how do you get the data back to the user. Is this a GUI app, or a web app, or what?

bwawok
It's a web app - in most cases the user won't need to see the update immediately anyhow.
bennylope
Okay so look into using a queue of some type to drop the work in and return. Other worker threads can pick up the work. Realize there are two types of threading.. lightweight (http://docs.python.org/library/threading.html#module-threading), and real (http://docs.python.org/library/multiprocessing.html). The lightweight threading module will just share CPU time with the main thread, while the "real" multiprocessing is real threading and will consume CPU time on other CPUs
bwawok
A: 

I use the producer consumer model with a RPCXML server for just this sort of thing. I start a pool of 3 threads, when someone requests something done (add file, etc) I add the work to the queue and return a key. an ajax request can check on the status of the key to set a progress bar, etc.

ebt