2009/1/9 Beetle B. <[email protected]>:
>
> On Jan 7, 4:13 am, Graham Dumpleton <[email protected]>
> wrote:
>> Because of those problems, Interpreter reloading was removed and
>> proper Process reloading added mod_wsgi 2.X as default instead for
>> mod_wsgi daemon mode. Thus, touching the WSGI script file now causes
>> whole daemon process to shutdown and new one created, just as if
>> Python process itself had been stopped an started.
>>
>> Just be aware that some packages, including lxml (because of
>> simplified GIL state API usage) and some older versions of psycopg2
>> (because of a bad coding), have problems running in sub interpreters
>> and must run in main interpreter in the process. This is a separate
>> issue to sub interpreter destruction problem. Thus, if using lxml, you
>> probably still need to delegate application to run in main interpreter
>> using:
>>
>> WSGIApplicationGroup %{GLOBAL}
>
> OK - Let me see if I have this right. If I'm using lxml or any other
> "problematic" module, and I use WSGIApplicationGroup as described,
> will I be able to safely have code changes register by simply touching
> the WSGI script?
They are two separate issues.
As long as you use mod_wsgi 2.X and have delegated application to
daemon mode, touching the WSGI script file will cause the daemon
processes in that group to be shutdown and restarted at the next
request received.
To clarify about WSGIApplicationGroup, for lxml, my understanding is
that so long as you do not use any features of lxml which would cause
it to execute a callback which you register with it, you do not need
to do anything. In the case of a callback being executed, because lxml
uses what is called the simplified API for GIL state manipulation,
basically thread lock stuff, if the call happens when running in any
sub interpreter, ie., not the primary main interpreter, then the code
will deadlock.
Thus you would need to set WSGIApplicationGroup to %{GLOBAL} to force
application to be run in context of the primary main interpreter
within the daemon process rather than the default, which would be a
sub interpreter named based on name of site and application mount
point.
In general, if only one WSGI application running in daemon process, is
generally a good idea to force application to run in main interpreter
anyway. That way you do not get any unexpected surprises with third
party C extension modules not doing the correct thing, or using APIs
in a way not compatible with sub interpreters.
So reloading has nothing to do with GIL state issues, the reloading
will work regardless.
> And if so, what are the downsides to using this method?
For reloading, none really. The overhead of the check is insignificant.
> The end goal is to be able to have code changes implemented without
> restarting Apache...
Which it allows.
Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
