[jira] Created: (MODPYTHON-60) PythonOption directive causes memory leak

2005-06-23 Thread Jim Gallacher (JIRA)
PythonOption directive causes memory leak - Key: MODPYTHON-60 URL: http://issues.apache.org/jira/browse/MODPYTHON-60 Project: mod_python Type: Bug Components: core Versions: 3.1.4, 3.1.3, 3.2.0 Environment: Linux

Re: Potential deadlock in psp.py

2005-06-23 Thread Gregory (Grisha) Trubetskoy
Is this reproducable? With a 1 in 31 chance it should be pretty easy to reproduce... Just want to make sure that there isn't some undrelying reason why this was done this way. Grisha On Thu, 23 Jun 2005, Jim Gallacher wrote: I think I just spotted a potential deadlock in psp.py. def dbm_c

Re: Potential deadlock in psp.py

2005-06-23 Thread Jim Gallacher
Gregory (Grisha) Trubetskoy wrote: Is this reproducable? With a 1 in 31 chance it should be pretty easy to reproduce... Just want to make sure that there isn't some undrelying reason why this was done this way. The supposition that there is a deadlock is untested and simply based on inspect

Re: Potential deadlock in psp.py

2005-06-23 Thread Nicolas Lehuen
Hi Jim, Until now, we suspected that the way global locks are handled could be deadlock prone. You have just proved it. I know that global locks are expensive on some systems, especially if we want to use them in a multiprocess (forked) environment. That's why we are forced to have such a small p

Re: Potential deadlock in psp.py

2005-06-23 Thread Jim Gallacher
Jim Gallacher wrote: Gregory (Grisha) Trubetskoy wrote: Is this reproducable? With a 1 in 31 chance it should be pretty easy to reproduce... Just want to make sure that there isn't some undrelying reason why this was done this way. The supposition that there is a deadlock is untested and

Re: Potential deadlock in psp.py

2005-06-23 Thread Jim Gallacher
Nicolas Lehuen wrote: Hi Jim, Until now, we suspected that the way global locks are handled could be deadlock prone. You have just proved it. I know that global locks are expensive on some systems, especially if we want to use them in a multiprocess (forked) environment. That's why we are force

Re: Potential deadlock in psp.py

2005-06-23 Thread Gregory (Grisha) Trubetskoy
Yeah, we've got to be inline with the HTTP Project - prefork is the default on unix systems, so we have to abide by it... So I guess the solution is that we need to reserve two locks instead of just one? Grisha On Thu, 23 Jun 2005, Jim Gallacher wrote: Nicolas Lehuen wrote: Hi Jim, Unt

Re: Potential deadlock in psp.py

2005-06-23 Thread Nicolas Lehuen
Well, why not keep the 32 session locks for sessions, and add something to the locking API so that we can create dedicated locks for dedicated usages (the session database lock, the PSP cache lock...) ? The next time someone will need a dedicated lock, he will be tempted to rely on the current im

Re: [jira] Created: (MODPYTHON-60) PythonOption directive causes memory leak

2005-06-23 Thread Nicolas Lehuen
It looks like that's the way to do it : http://modules.apache.org/doc/API.html#per-dir http://www.apachetutor.org/dev/config But the memory management seems very mysterious to me here... I can't find anything that looks like a destructor for the py_config structure ! Regards, Nicolas 2005/6/24,

Re: [jira] Created: (MODPYTHON-60) PythonOption directive causes memory leak

2005-06-23 Thread Nicolas Lehuen
OK, anything allocated to a pool is automatically deallocated by the pool when it is cleared, which should be at the end of a request : http://www.apachetutor.org/dev/pools So if there is a memory leak, it should not be caused by something allocated to a pool. Regards, Nicolas 2005/6/24, Nicola