Re: mutex dir?
torsdagen den 16 februari 2006 22.48 skrev Jim Gallacher: > Oden Eriksson wrote: > > tisdagen den 14 februari 2006 13.17 skrev Oden Eriksson: > >>Hello. > > > > [...] > > > > I am no programmer, but can't you just look at how this is handled in the > > core mod_ssl and ldap code? > > That would be cheating and no fun at all! ;) > > Seriously though, we do often look through the source of other modules > for ideas and inspiration, but the code bases are different enough that > it's not a simple cut and paste. I know it may seem like we've gone off > on a tangent, but I think it's better to come up with a general solution > rather than creating a bunch of special cases, each of which end up with > a slightly different implementation. He he he, I see. Then it wasn't just me who thought this was not a cut and paste thing. I also looked in many other third party modules to see if I could do that :) -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
Re: mutex dir?
On 17/02/2006, at 10:01 AM, Jim Gallacher wrote:
The ap_check_cmd_context function may also be of interest.
http://docx.webperf.org/group__ap__check__cmd__context.html
For example, lets say we wanted to disallow the use of PythonDebug
in
const char *err;
if ((err = ap_check_cmd_context(cmd, NOT_IN_VIRTUALHOST))) {
return err;
} else {
/* do some processing */
}
The one I can't find a good way of doing is, how do I determine if a
directive
was used in a .htaccess file.
If you use a directive in a container, you will know
because you
can search back through parent containers of command and find it. For a
.htaccess file, I would have assumed there would have been an implicit
container created or some other indicator, but I can't
find any.
The only kludge I can even dream of at the moment is to rely on the fact
that the filename attribute will identify the full path to
the .htaccess file. If I
can be sure that it is a .htaccess file, I can take the dirname of it
and use that
as the req.hlist.directory.
The particular problem I am trying to solve is the PythonHandler in
container inside of a .htaccess file. Ie., MODPYTHON-126.
Don't know how to work that one out do you? :-(
Graham
Re: mutex dir?
Graham Dumpleton wrote:
Graham Dumpleton wrote ..
Graham Dumpleton wrote ..
How does req.server.get_options() differ from req.server.get_config(),
which already exists?
I still see what is in get_config() as special, ie., the values for
actual directives. Just don't think it is good to mix them.
Looking at this further, the distinction between req.get_config() and
req.server.get_config() seems to be all broken. The code for PythonDebug
is:
/**
** directive_PythonDebug
**
* This function called whenever PythonDebug directive
* is encountered.
*/
static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
int val) {
const char *rc = python_directive_flag(mconfig, "PythonDebug", val,
0);
if (!rc) {
py_config *conf = ap_get_module_config(cmd->server->module_config,
&python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
}
return rc;
}
The python_directive_flag() function always returns NULL and so it adds
the config value to both table objects. This means that local values for
the directives in a directory/location/files/host context are going to
overwrite the global ones in req.server.
This code should perhaps similarly be looking to see if cmd->path is
NULL.
Thus, FWIW, I get what I would expect when I change the code to:
/**
** directive_PythonDebug
**
* This function called whenever PythonDebug directive
* is encountered.
*/
static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
int val) {
const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
if (!cmd->path) {
py_config *conf = ap_get_module_config(cmd->server->module_config,
&python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
}
return rc;
}
It isn't just this directive processor though, all of them should have:
if (!rc) {
changed to:
if (!cmd->path) {
The actual return values from the function are really meaningless as
they are always NULL.
The ap_check_cmd_context function may also be of interest.
http://docx.webperf.org/group__ap__check__cmd__context.html
For example, lets say we wanted to disallow the use of PythonDebug in
const char *err;
if ((err = ap_check_cmd_context(cmd, NOT_IN_VIRTUALHOST))) {
return err;
} else {
/* do some processing */
}
Jim
Re: mutex dir?
Oden Eriksson wrote: tisdagen den 14 februari 2006 13.17 skrev Oden Eriksson: Hello. [...] I am no programmer, but can't you just look at how this is handled in the core mod_ssl and ldap code? That would be cheating and no fun at all! ;) Seriously though, we do often look through the source of other modules for ideas and inspiration, but the code bases are different enough that it's not a simple cut and paste. I know it may seem like we've gone off on a tangent, but I think it's better to come up with a general solution rather than creating a bunch of special cases, each of which end up with a slightly different implementation. Jim
Re: mutex dir?
Graham Dumpleton wrote ..
> Graham Dumpleton wrote ..
> > > How does req.server.get_options() differ from req.server.get_config(),
> > > which already exists?
> >
> > I still see what is in get_config() as special, ie., the values for
> > actual directives. Just don't think it is good to mix them.
>
> Looking at this further, the distinction between req.get_config() and
> req.server.get_config() seems to be all broken. The code for PythonDebug
> is:
>
> /**
> ** directive_PythonDebug
> **
> * This function called whenever PythonDebug directive
> * is encountered.
> */
> static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
> int val) {
> const char *rc = python_directive_flag(mconfig, "PythonDebug", val,
> 0);
>
> if (!rc) {
> py_config *conf = ap_get_module_config(cmd->server->module_config,
>&python_module);
>
> return python_directive_flag(conf, "PythonDebug", val, 0);
> }
> return rc;
> }
>
> The python_directive_flag() function always returns NULL and so it adds
> the config value to both table objects. This means that local values for
> the directives in a directory/location/files/host context are going to
> overwrite the global ones in req.server.
>
> This code should perhaps similarly be looking to see if cmd->path is
> NULL.
Thus, FWIW, I get what I would expect when I change the code to:
/**
** directive_PythonDebug
**
* This function called whenever PythonDebug directive
* is encountered.
*/
static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
int val) {
const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
if (!cmd->path) {
py_config *conf = ap_get_module_config(cmd->server->module_config,
&python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
}
return rc;
}
It isn't just this directive processor though, all of them should have:
if (!rc) {
changed to:
if (!cmd->path) {
The actual return values from the function are really meaningless as
they are always NULL.
Graham
Re: mutex dir?
Graham Dumpleton wrote ..
> > How does req.server.get_options() differ from req.server.get_config(),
> > which already exists?
>
> I still see what is in get_config() as special, ie., the values for
> actual directives. Just don't think it is good to mix them.
Looking at this further, the distinction between req.get_config() and
req.server.get_config() seems to be all broken. The code for PythonDebug
is:
/**
** directive_PythonDebug
**
* This function called whenever PythonDebug directive
* is encountered.
*/
static const char *directive_PythonDebug(cmd_parms *cmd, void *mconfig,
int val) {
const char *rc = python_directive_flag(mconfig, "PythonDebug", val, 0);
if (!rc) {
py_config *conf = ap_get_module_config(cmd->server->module_config,
&python_module);
return python_directive_flag(conf, "PythonDebug", val, 0);
}
return rc;
}
The python_directive_flag() function always returns NULL and so it adds
the config value to both table objects. This means that local values for
the directives in a directory/location/files/host context are going to
overwrite the global ones in req.server.
This code should perhaps similarly be looking to see if cmd->path is
NULL. Before we decide that, we probably need to clarify what is
actually mean't by the req.server.get_config() documentation. Ie.,
what is it supposed to return in the first place.
get_config( )
Similar to req.get_config(), but returns a config pointed to by
server->module_config Apache config vector.
My assumption would be like in example in previous email for the
PythonOption directive, is that it is the original values for the directives
when defined outside of all containers. What the documentation
says doesn't mean much and doesn't really say this.
Thus, what do people think that req.server.get_config() is mean't
to return in comparison to req.get_config().
Graham
Re: mutex dir?
Jim Gallacher wrote ..
> > I have a better option (pun intended). :-)
> >
> > We do not need a new directive. Instead use existing "PythonOption"
> > directive.
>
> That could work.
>
> > In the handler code for the directive, it can look at the
> > value of the "cmd_parms->path" and determine if it is being used outside
> > of all VirtualHost, Directory, Location, File directives, ie., at global
> > scope "path" will be NULL.
>
> The disadvantage is that every request which triggers the
> directive_PythonOption call would require a number of string
> comparisons. Granted this is done in C, but there is a penalty to be paid.
No. No string comparisons at all. Check that cmd->path == NULL only.
> > If it is, then stick it in a table object associated
> > with the server level config for mod_python. This would then be accessible
> > as: "req.server.get_options()".
>
> Do you see us adding a new apr_table_t field to the py_config structure
> (define in mod_python.h)? Or would these server options go in either the
> directives or options table?
Hmmm, this is interesting. It seems that the code may have intended to
implement the exact feature I was talking about but it wasn't completed.
The code has:
static const char *directive_PythonOption(cmd_parms *cmd, void * mconfig,
const char *key, const char *val)
{
py_config *conf;
conf = (py_config *) mconfig;
if(val!=NULL) {
apr_table_set(conf->options, key, val);
conf = ap_get_module_config(cmd->server->module_config,
&python_module);
apr_table_set(conf->options, key, val);
}
else {
/** We don't remove the value, but set it
to an empty string. There is no possibility
of colliding with an actual value, since
an entry string precisely means 'remove the value' */
apr_table_set(conf->options, key, "");
conf = ap_get_module_config(cmd->server->module_config,
&python_module);
apr_table_set(conf->options, key, "");
}
return NULL;
}
It was already setting the options table object in the server config
object, but was doing it no matter where in config. Thus no different
to request object. If instead it is written as:
static const char *directive_PythonOption(cmd_parms *cmd, void * mconfig,
const char *key, const char *val)
{
py_config *conf;
conf = (py_config *) mconfig;
if(val!=NULL) {
apr_table_set(conf->options, key, val);
if (cmd->path == NULL) {
conf = ap_get_module_config(cmd->server->module_config,
&python_module);
apr_table_set(conf->options, key, val);
}
}
else {
/** We don't remove the value, but set it
to an empty string. There is no possibility
of colliding with an actual value, since
an entry string precisely means 'remove the value' */
apr_table_set(conf->options, key, "");
if (cmd->path == NULL) {
conf = ap_get_module_config(cmd->server->module_config,
&python_module);
apr_table_set(conf->options, key, "");
}
}
return NULL;
}
Then it then correctly separates the global from the non global.
The merging code already merges the two back together to
construct the actual request object.
Code will actually run quicker than before, as have avoided inserting
values into two tables when not global config.
The only thing then missing is in serverobject.c, which needs:
/**
** server.get_options(server self)
**
* Returns the options set through PythonOption directives.
* unlike req.get_options, this one returns the per-server config
*/
static PyObject * server_get_options(serverobject *self)
{
py_config *conf =
(py_config *) ap_get_module_config(self->server->module_config,
&python_module);
return MpTable_FromTable(conf->options);
}
static PyMethodDef server_methods[] = {
{"get_config", (PyCFunction) server_get_config,
METH_NOARGS},
{"get_options", (PyCFunction) server_get_options,
METH_NOARGS},
{"register_cleanup", (PyCFunction) server_register_cleanup,
METH_VARARGS},
{ NULL, NULL } /* sentinel */
};
If I then have at global config scope:
PythonOption global 1
PythonOption override 1
and in a .htaccess file:
PythonOption local 1
PythonOption override 2
The end result is:
req.get_options()={'local': '1', 'override': '2', 'global': '1'}
req.server.get_options()={'override': '1', 'global': '1'}
> How does req.server.get_options() differ from req.server.get_config(),
> which already exists?
I still see what is in get_config() as special, ie., the values for
actual directives. Just don't think it
Re: mutex dir?
Graham Dumpleton wrote: Jim Gallacher wrote .. If the settings are going to be a generic key/value like in PythonOption, but only for purposes of the mod_python system itself, maybe it should be called PythonSystemOption. Prefer PythonSystemOption as "Module" is too confusing to me given you have both Apache modules and Python modules and a module importer. Fair enough. PythonSystemOption is a better. The directive definition is such that it cannot be used in VirtualHost, Directory, Location and so on which should help emphasize that it's use in only for configuring mod_python.so initialization. Also wary of "Config" because of confusion with "req.get_config()". Except that PythonSystemOption just stuffs strings into server->module_config->directives table, which can be accessed via req.server.get_config(). I can't see any reason application code will ever need the settings PythonSystemOption might set, so it's not a big deal if it's not obvious from the name that the settings can be retrieved with get_config. I like the new name as it signals our intention of how PythonSystemOption should be used. This name is also consistent with PythonOption, which is a good idea. I have a better option (pun intended). :-) We do not need a new directive. Instead use existing "PythonOption" directive. That could work. In the handler code for the directive, it can look at the value of the "cmd_parms->path" and determine if it is being used outside of all VirtualHost, Directory, Location, File directives, ie., at global scope "path" will be NULL. The disadvantage is that every request which triggers the directive_PythonOption call would require a number of string comparisons. Granted this is done in C, but there is a penalty to be paid. If it is, then stick it in a table object associated with the server level config for mod_python. This would then be accessible as: "req.server.get_options()". Do you see us adding a new apr_table_t field to the py_config structure (define in mod_python.h)? Or would these server options go in either the directives or options table? How does req.server.get_options() differ from req.server.get_config(), which already exists? And lest we forget the original intent of this discussion, we want this so we can pass runtime configuration information during mod_python initialization. Maybe it really is more logical to have a new directive rather than overloading the behaviour of PythonOption. Because "PythonOption" as used now at global scope results in options being seen in "req.get_options()", so that still works, we merge the server options into the request one before overlaying it with the request specific options. In other words "req.get_options()" is just like now, but "req.server.get_options()" becomes the subset of options which were defined at global server scope. Anything used by mod_python itself would use a namespace prefix of "mod_python." as discussed before. Eg. PythonOption mod_python.mutex_directory It goes without saying that we would be using the new namespace. :) We can also make use the server->is_virtual field. This is false when init_mutexes is first called. (This statement really doesn't connect with the rest of the discussion, but it looks like it could be useful so I wanted to share). Jim
Re: mutex dir?
Jim Gallacher wrote .. > > If the settings are going to be a generic key/value like in > > PythonOption, but only for purposes of the mod_python system itself, > > maybe it should be called PythonSystemOption. Prefer PythonSystemOption > > as "Module" is too confusing to me given you have both Apache modules > > and Python modules and a module importer. > > Fair enough. PythonSystemOption is a better. The directive definition is > such that it cannot be used in VirtualHost, Directory, Location and so > on which should help emphasize that it's use in only for configuring > mod_python.so initialization. > > > Also wary of "Config" because > > of confusion with "req.get_config()". > > Except that PythonSystemOption just stuffs strings into > server->module_config->directives table, which can be accessed via > req.server.get_config(). I can't see any reason application code will > ever need the settings PythonSystemOption might set, so it's not a big > deal if it's not obvious from the name that the settings can be > retrieved with get_config. I like the new name as it signals our > intention of how PythonSystemOption should be used. This name is also > consistent with PythonOption, which is a good idea. I have a better option (pun intended). :-) We do not need a new directive. Instead use existing "PythonOption" directive. In the handler code for the directive, it can look at the value of the "cmd_parms->path" and determine if it is being used outside of all VirtualHost, Directory, Location, File directives, ie., at global scope "path" will be NULL. If it is, then stick it in a table object associated with the server level config for mod_python. This would then be accessible as: "req.server.get_options()". Because "PythonOption" as used now at global scope results in options being seen in "req.get_options()", so that still works, we merge the server options into the request one before overlaying it with the request specific options. In other words "req.get_options()" is just like now, but "req.server.get_options()" becomes the subset of options which were defined at global server scope. Anything used by mod_python itself would use a namespace prefix of "mod_python." as discussed before. Eg. PythonOption mod_python.mutex_directory Thus, existing directive is used and just needs to be stated that option is only used if at global server scope. Graham
Re: mutex dir?
Graham Dumpleton wrote: Hmmm, somehow I managed to vapourise an email, didn't even get to my sent mail box. Let me try this again. Jim Gallacher wrote .. Graham Dumpleton wrote: Correct, is actually done from the mod_python module init function. The only way one could have it dynamically changing is through an Apache -D option checked by using ap_exists_config_define(). This is incorrect. You can get at the directives from python_init. Proof of concept patch attached. Apply the patch and add the following directives in your apache config after the LoadModule. LoadModule python_module /usr/lib/apache2/modules/mod_python.so PythonModuleConfig max_locks 911 PythonModuleConfig mutex_dir /some/place/safe Check the error.log for the results. I'm sure I don't need to tell everyone that this is intend as Proof of Concept only. Don't blame me if your hair catches on fire and your teeth fall out as a result of using this patch. :) I don't have much hair left, so I better believe you. Thus I stand corrected. I also should look more closely at the code before I send off email. :-) If the settings are going to be a generic key/value like in PythonOption, but only for purposes of the mod_python system itself, maybe it should be called PythonSystemOption. Prefer PythonSystemOption as "Module" is too confusing to me given you have both Apache modules and Python modules and a module importer. Fair enough. PythonSystemOption is a better. The directive definition is such that it cannot be used in VirtualHost, Directory, Location and so on which should help emphasize that it's use in only for configuring mod_python.so initialization. Also wary of "Config" because of confusion with "req.get_config()". Except that PythonSystemOption just stuffs strings into server->module_config->directives table, which can be accessed via req.server.get_config(). I can't see any reason application code will ever need the settings PythonSystemOption might set, so it's not a big deal if it's not obvious from the name that the settings can be retrieved with get_config. I like the new name as it signals our intention of how PythonSystemOption should be used. This name is also consistent with PythonOption, which is a good idea. Other than that, probably is reasonable. What other configuration things are there like this that could be handled in the same way? I don't know, but I'm sure other uses may arise. That's why I'd favour a generic directive rather than a bunch of specific directives such as PythonMutexDirectory, etc. The key/value pairs generated when the PythonSystemOption directive is encountered are simply placed in the same table as directives such as PythonDebug and PythonPath. The difference is that these other directives cause their respective functions to be called where other processing, such as changing the debug flag, takes place. Would it be possible using such a thing to specify a directory that could be prefixed to sys.path to say where mod_python Apache module should look for mod_python Python modules? If we modify the code to check the module_config->directives table for an appropriate key/value pair, then sure, why not? It is always a pain to debug sometimes when people have multiple versions of Python and for various reasons their Apache environment means it is finding wrong mod_python modules. If had way of saying where it was, could override it as way of proving one way or another it is a problem. Yes/No? This new directive might be of use in other places if you want a way to pass arbitrary key/value pairs from the apache config into mod_python. Any code section that has access to the server_rec could make use of it. Jim
Re: mutex dir?
Hmmm, somehow I managed to vapourise an email, didn't even get to my sent mail box. Let me try this again. Jim Gallacher wrote .. > Graham Dumpleton wrote: > > Correct, is actually done from the mod_python module init function. > > > > The only way one could have it dynamically changing is through an > > Apache -D option checked by using ap_exists_config_define(). > > This is incorrect. You can get at the directives from python_init. Proof > of concept patch attached. Apply the patch and add the following > directives in your apache config after the LoadModule. > > LoadModule python_module /usr/lib/apache2/modules/mod_python.so > PythonModuleConfig max_locks 911 > PythonModuleConfig mutex_dir /some/place/safe > > Check the error.log for the results. > > I'm sure I don't need to tell everyone that this is intend as Proof of > Concept only. Don't blame me if your hair catches on fire and your teeth > fall out as a result of using this patch. :) I don't have much hair left, so I better believe you. Thus I stand corrected. I also should look more closely at the code before I send off email. :-) If the settings are going to be a generic key/value like in PythonOption, but only for purposes of the mod_python system itself, maybe it should be called PythonSystemOption. Prefer PythonSystemOption as "Module" is too confusing to me given you have both Apache modules and Python modules and a module importer. Also wary of "Config" because of confusion with "req.get_config()". Other than that, probably is reasonable. What other configuration things are there like this that could be handled in the same way? Would it be possible using such a thing to specify a directory that could be prefixed to sys.path to say where mod_python Apache module should look for mod_python Python modules? It is always a pain to debug sometimes when people have multiple versions of Python and for various reasons their Apache environment means it is finding wrong mod_python modules. If had way of saying where it was, could override it as way of proving one way or another it is a problem. Yes/No? Graham
Re: mutex dir?
Graham Dumpleton wrote:
Grisha wrote ..
On Tue, 14 Feb 2006, Jim Gallacher wrote:
I wonder if we should generalize this, so rather than PythonMutexDir,
we have
PythonModuleConfig. Usage might look like:
PythonModuleConfig mutex_dir /path/to/mutexs
PythonModuleConfig max_mutex_locks 8
I may be wrong, but I think the reason this was never configurable was
because the mutex is created before the apache config is read.
Correct, is actually done from the mod_python module init function.
The only way one could have it dynamically changing is through an
Apache -D option checked by using ap_exists_config_define().
This is incorrect. You can get at the directives from python_init. Proof
of concept patch attached. Apply the patch and add the following
directives in your apache config after the LoadModule.
LoadModule python_module /usr/lib/apache2/modules/mod_python.so
PythonModuleConfig max_locks 911
PythonModuleConfig mutex_dir /some/place/safe
Check the error.log for the results.
I'm sure I don't need to tell everyone that this is intend as Proof of
Concept only. Don't blame me if your hair catches on fire and your teeth
fall out as a result of using this patch. :)
Jim
Index: src/mod_python.c
===
--- src/mod_python.c(revision 377430)
+++ src/mod_python.c(working copy)
@@ -314,7 +314,25 @@
int max_clients;
int locks;
int n;
+
+/* PythonModuleConfig Proof of Concept */
+char *val;
+py_config *conf =
+(py_config *) ap_get_module_config(s->module_config,
+ &python_module);
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s,
+ "TEST init_mutexes: checking for values set by
PythonModuleConfig");
+
+val = apr_table_get(conf->directives, "max_locks");
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s,
+ "TEST init_mutexes: max_locks = %s", val);
+
+val = apr_table_get(conf->directives, "mutex_dir");
+ap_log_error(APLOG_MARK, APLOG_NOTICE, 0, s,
+ "TEST init_mutexes: mutex_dir = %s", val);
+/* end POC */
+
/* figre out maximum possible concurrent connections */
/* MAX_DAEMON_USED seems to account for MaxClients, as opposed to
MAX_DAEMONS, which is ServerLimit
@@ -1621,7 +1639,45 @@
return NULL;
}
+
/**
+ ** directive_PythonModuleConfig
+ **
+ * This function called whenever PythonModuleConfig directive
+ * is encountered.
+ *
+ * WARNING WARNING WARNING
+ * This is proof of concept code
+ * DO NOT USE IN PRODUCTION
+ */
+static const char *directive_PythonModuleConfig(cmd_parms *cmd, void *
mconfig,
+ const char *key, const char *val)
+{
+py_config *conf;
+conf = (py_config *) mconfig;
+if(val!=NULL) {
+apr_table_set(conf->options, key, val);
+
+conf = ap_get_module_config(cmd->server->module_config,
+&python_module);
+apr_table_set(conf->directives, key, val);
+}
+else {
+ /** We don't remove the value, but set it
+ to an empty string. There is no possibility
+ of colliding with an actual value, since
+ an entry string precisely means 'remove the value' */
+apr_table_set(conf->directives, key, "");
+
+conf = ap_get_module_config(cmd->server->module_config,
+&python_module);
+apr_table_set(conf->directives, key, "");
+}
+return NULL;
+}
+
+
+/**
** directive_PythonOptimize
**
* This function called whenever PythonOptimize directive
@@ -2131,6 +2187,9 @@
AP_INIT_TAKE12(
"PythonOutputFilter", directive_PythonOutputFilter, NULL,
RSRC_CONF|ACCESS_CONF,
"Python output filter."),
+AP_INIT_TAKE12(
+"PythonModuleConfig", directive_PythonModuleConfig, NULL, RSRC_CONF,
+"Python module configuration."),
{NULL}
};
Re: mutex dir?
Grisha wrote .. > > On Tue, 14 Feb 2006, Jim Gallacher wrote: > > > I wonder if we should generalize this, so rather than PythonMutexDir, > we have > > PythonModuleConfig. Usage might look like: > > > > PythonModuleConfig mutex_dir /path/to/mutexs > > PythonModuleConfig max_mutex_locks 8 > > I may be wrong, but I think the reason this was never configurable was > because the mutex is created before the apache config is read. Correct, is actually done from the mod_python module init function. The only way one could have it dynamically changing is through an Apache -D option checked by using ap_exists_config_define(). Not too useful for general use, but may be necessary when running test suite to avoid clashes if it is that big a problem. Graham
Re: mutex dir?
On Tue, 14 Feb 2006, Jim Gallacher wrote: I wonder if we should generalize this, so rather than PythonMutexDir, we have PythonModuleConfig. Usage might look like: PythonModuleConfig mutex_dir /path/to/mutexs PythonModuleConfig max_mutex_locks 8 I may be wrong, but I think the reason this was never configurable was because the mutex is created before the apache config is read. Grisha
Re: mutex dir?
tisdagen den 14 februari 2006 18.35 skrev Jim Gallacher: > Oden Eriksson wrote: > > tisdagen den 14 februari 2006 14.19 skrev Jim Gallacher: > >>Oden Eriksson wrote: > >>>Hello. > >>> > >>>In our package in Mandriva I patch mod_python.c so that the mutex stuff > >>>is put in "/var/cache/httpd/mod_python/". But now with mod_python-3.2.7 > >>>plus fixes from the trunk and running the test suite it complains it > >>>cannot access "/var/cache/httpd/mod_python/" (of course). So my > >>>question/request is, could you please make this directory set in the > >>>config? > >> > >>I assume you mean as an option to configure, rather than as an Apache > >>configuration directive? > > > > I meant as an apache configuration directive. > > After giving this some thought I think it should be both, so the options > become: > > 1. Default /tmp > > 2. --configure --with-mutex-dir=/some/directory > Allows distributions to package mod_python according to their > platform specification, without the need for applying any patches. > > 3. PythonMutexDir /some/place > This would mainly be used in the unit tests to override the setting > applied by option #2. This avoids Oden's unit test problem which is > similar to the problem described in MODPYTHON-119, where the unit test > defaults may conflict with a mod_python instance running on the server. Looks good to me. Please make sure the test case will survive too. Currently the test case fails all over the place for me... Why don't you write the test cases so that you can use Apache-Test? > I wonder if we should generalize this, so rather than PythonMutexDir, we > have PythonModuleConfig. Usage might look like: > > PythonModuleConfig mutex_dir /path/to/mutexs > PythonModuleConfig max_mutex_locks 8 > > Currently the number of mutex locks is set with ./configure > --with-max-locks Looks very good. I was planning to make an optional rpm build switch so that you could rebuild the src.rpm so that you could use any number there. Speaking of locks, I think this could be improved a bit so that you don't have to use ipc for example. History has shown ipc semaphore locks are not very stable on linux. > By the way Oden, are you the offical mod_python maintainer on Mandriva? Amongst many other packages (too many), yes. -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
mutex dir?
Hello. In our package in Mandriva I patch mod_python.c so that the mutex stuff is put in "/var/cache/httpd/mod_python/". But now with mod_python-3.2.7 plus fixes from the trunk and running the test suite it complains it cannot access "/var/cache/httpd/mod_python/" (of course). So my question/request is, could you please make this directory set in the config? -- Regards // Oden Eriksson Mandriva: http://www.mandriva.com NUX: http://li.nux.se
