Re: [jira] Commented: (MODPYTHON-202) Allow mechanism used by globalmutex locks to be specified.

2006-11-09 Thread Graham Dumpleton
Jim Gallacher wrote ..
 Graham Dumpleton (JIRA) wrote:
  [ 
  http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585
 ] 
  
  Graham Dumpleton commented on MODPYTHON-202:
  
  
  A configuration option can possibly be modelled off how the AcceptMutex
 directive for Apache works. Ie:
  
http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex
  
  Would just need to decide whether we do it as a PythonOption or introduce
 a new directive instead.
 
 We seem to be going pretty far down the road with PythonOption and our
 new namespace, so I'm inclined to stick with that, unless there is some
 sort of performance implication.

An option for this would be like the number of mutex locks in that it is only
checked at mod_python startup, thus performance is not an issue. FWIW, I
have no problem with continuing with PythonOption for these things. Certainly
saves all the extra coding required to add a new directive. :-)

Graham


Re: [jira] Commented: (MODPYTHON-202) Allow mechanism used by globalmutex locks to be specified.

2006-11-09 Thread Jim Gallacher

Graham Dumpleton wrote:

Jim Gallacher wrote ..

Graham Dumpleton (JIRA) wrote:

[ 
http://issues.apache.org/jira/browse/MODPYTHON-202?page=comments#action_12448585
] 

Graham Dumpleton commented on MODPYTHON-202:



A configuration option can possibly be modelled off how the AcceptMutex

directive for Apache works. Ie:

  http://httpd.apache.org/docs/2.2/mod/mpm_common.html#acceptmutex

Would just need to decide whether we do it as a PythonOption or introduce

a new directive instead.

We seem to be going pretty far down the road with PythonOption and our
new namespace, so I'm inclined to stick with that, unless there is some
sort of performance implication.


An option for this would be like the number of mutex locks in that it is only
checked at mod_python startup, thus performance is not an issue. 


I was thinking more along the lines of the configuration context - 
PythonOption can be anywhere, so you could end up with a bloated 
dictionary. This is likely to be a minor quibble though. I'm sure we can 
find other places to optimize first. I keep wondering how FieldStorage 
might behave if it was written in C. ;)




FWIW, I
have no problem with continuing with PythonOption for these things. Certainly
saves all the extra coding required to add a new directive. :-)


Exactly. Less code == fewer bugs.

Jim