When things get murky, WinPDB http://winpdb.org/ is your best friend. Despite the unfortunate name, it has nothing to do with Windows. It's a free thread and fork aware python debugger. You can learn an amazing amount about what's going on under the hood in a very short time. Cheers, Mike
On Sep 2, 10:10 am, Jonathan Lundell <[email protected]> wrote: > On Sep 1, 2011, at 11:57 PM, Henri Heinonen wrote: > > > 2011/9/1 Jonathan Lundell <[email protected]> > > If it's convenient, you might experiment with calling time.sleep(0) fairly > > frequently in your CPU-bound simulation app, perhaps in some inner loop, to > > yield to other threads. > > > I tried time.sleep(0), but it didn't have any effect. > > > I tried time.sleep(0.1), but it made the simulation very slow and it didn't > > have any effect on welcome application, which didn't respond at all during > > the simulation. > > > Another (or supplementary) approach is to serialize your simulations, which > > might take some refactoring. The idea here is to have a single thread that > > runs the simulations from a queue, one at a time, so only one simulation > > thread is contending for CPU resources. > > > Sounds complicated. > > > Or push the simulations into another process altogether, and use the OS's > > process priority mechanisms. > > > Ok. Maybe I'll give this a try. > > Is it possible that you're running into some locked-resource conflict? A > database, perhaps? > > I ask because if the sleep(0.1) significantly slowed the simulation and > didn't help the interactive app, it suggests that there's a problem other > than sheer CPU usage.
