[mod_python] implications of multiple interpreters

On 05/05/07, John Raines <jrraines at comcast.net> wrote:
> My point was that there is presumably one global flag that tells the
> calendar module whether the first weekday is Sunday or Monday. I'm
> presuming that if one subinterpreter changes the default Monday to
> Sunday that all the subinterpreters also see this happen. The flag
> iprobably isn't set on a per interpreter basis

>From reading 'calendar' code, it would be on per interpreter basis. It
is not global across all sub interpreters within that process. Such
global state across all interpreters would generally only occur in C
extension modules where flag is maintained in C code and not Python
code.

> and even if it were, a
> browser client isn't guarranteed the same subinterpreter on the next
> request.

You might be getting confused with fact that subsequent request may
actually be against a different process. Read:

  http://www.dscpl.com.au/wiki/ModPython/Articles/TheProcessInterpreterModel

The request for a particular URL will always be against the same named
interpreter, but there is a unique instance of that named interpreter
in each Apache child process that might handle a request. Within one
process that one instance of a specific named interpreter persists for
the life of that process.

> The first weekday needs to be restored to the default and the end of
> each page request  and if the client wants something else, it will
> need to be set up each  request by some mechanism usng cookies or
> sessions or something similar.  The first weekday thing can be set
> but not directly read; you can figure out what it is by looking at
> the returned calendar for a specific month.

Setting flag at beginning of request and restoring it at the end of
the request will not work in a multithread Apache MPM as the use of
the flag in a particular state will not be serialised. Thus one
request when cleaning up could set flag back to different value for
other request got to use it with state it had just set it to.

In other words, changing that state in 'calender' is not thread safe
and should only be changed once from module imported using
PythonImport and left that way for life of process.

>   If  I understood the python 3.0 issue it was similar to this, but
> more difficult: they were considering adding the ability to override
> arithmetic operators for some classes and this would be global
> behavior. There would typically be no way to reset THAT to default
> and restore it  to what was wanted on each request.

It was only an issue with Python 3.0 and what they were talking about
because they were talking about making changes at C code level and not
at that point taking into consideration that behaviour may want to be
different where there are multiple sub interpreters.

Graham

> On May 4, 2007, at 10:19 PM, Graham Dumpleton wrote:
>
> > As 'calendar' is a pure Python module any problem wouldn't be anything
> > to do with multiple sub interpreters as each sub interpreter has its
> > own copy of pure Python code modules. Any problem you saw is more
> > likely the result of using the Apache worker MPM on UNIX, or using a
> > Windows box, and the fact that distinct requests can be running
> > concurrently within the one sub interpreter of a process in different
> > threads.
> >
> > Graham
> >
> > On 04/05/07, John Raines <jrraines at comcast.net> wrote:
> >> Last night I found a bug in my code that involved using
> >> calendar.setfirstweekday in one place and later assuming that it was
> >> the default at another place (actually an earlier place that I came
> >> back to).
> >>
> >> As I think about this there may be an interaction with multiple
> >> interpreters so that this MIGHTt ave been hard to reproduce and find.
> >> I fixed my problem but I am interested in understanding the
> >> implications of multiple interpreters for issues of this sort.
> >>
> >> I suspect this is not dissimilar to the brief thread earlier in the
> >> week about python 3.0.
> >> _______________________________________________
> >> Mod_python mailing list
> >> Mod_python at modpython.org
> >> http://mailman.modpython.org/mailman/listinfo/mod_python
> >>
>
>