Forking and Threads

[Paul Robinson]

Tim Peters wrote:
> 
> [posted & mailed]
> 
> [Paul Robinson]
> > ...
> > http://cobweb.quantisci.co.uk/pub/english.cgi/d10030658/forkingtest2.py
> > ) will run happily for several minutes (upto about 10mins so far) and
> > then just sit there with the main process running with as much CPU time
> > as the OS will give it!

> Try it under Python 2.0.

That was one of my thoughts as well. It ran successfully overnight using
Python 2.0 on the same system.

> 2.0 "fixed" that via brute force
> panic:  after a fork, the child allocates a brand new interpreter lock for
> its own use; it leaks the one inherited from the parent process.

I didn't check the memory usage before I terminated the run this
morning. Should I be expecting significant resource leakage with a long
(and I mean looong) running process?
If the leak is in the forked child then that shouldn't be a problem as
they are short lived.

> Nobody was
> able to do substantially better than this despite countless hours of trying,
> so, under the assumption that it was a Linux bug that would eventually get
> fixed, we all forgot about it.

Hmm. OK. That just leaves me in a slightly tricky situation of verifying
that the other few hundred thousand LOC that make up the software
product also work with Python 2.0! - we had that scheduled for April but
this set back might require being slightly more flexible.

Is there any suggestion of how I could do something similar (or work
around the problem) using 1.5.2?

Thanks for the advice.

Paul Robinson
Business Collaborator Development Manager
Enviros Software Solutions
WWW: http://www.businesscollaborator.com