Tried against current mod_wsgi sources in Debian (v3.3). This actually
solves the issue - well done!
Best regards,
Andreas
On 17.03.2011 23:39, Graham Dumpleton wrote:
> My first attempts to reproduce this in MacOS X didn't work.
>
> What I did do though is modify mod_wsgi C code to do stuff that would
> force loading of encoding/codes modules for sub interpreters. Ie.,
> added:
>
> Index: mod_wsgi.c
> ===================================================================
> --- mod_wsgi.c (revision 1755)
> +++ mod_wsgi.c (working copy)
> @@ -4393,6 +4393,17 @@
> }
>
> /*
> + * Force loading of codecs into interpreter. This has to be
> + * done as not otherwise done in sub interpreters and if not
> + * done, code running in sub interpreters can fail on some
> + * platforms if a unicode string is added in sys.path and an
> + * import then done.
> + */
> +
> + item = PyCodec_Encoder("ascii");
> + Py_XDECREF(item);
> +
> + /*
> * If running in daemon process, override as appropriate
> * the USER, USERNAME or LOGNAME environment variables
> * so that they match the user that the process is running
>
> If you were eager to try this patch and see if it fixes issue then
> patch will likely not apply properly as mod_wsgi code for 4.0 has
> moved around a fair bit and line numbers will be way off. The two
> lines though are added to newInterpreterObject() just before
> USER/USERNAME/LOGNAME are setup for daemon mode processes.
>
> Graham
>
> On 16 March 2011 10:21, Andreas Sommer <[email protected]>
> wrote:
>> It did not even try to import them. You can see the sys.modules state of the
>> WSGI script in my previous response (no "encodings" and "codecs" modules
>> imported) and I also verified that with file-write debugging in the
>> "encodings" module - it really does not get loaded in the subinterpreters.
>>
>> On 16.03.2011 16:37, Joonas Lehtolahti wrote:
>>
>> [cut out the long post]
>>
>> Interesting, it seems like there really happens a difference between
>> initialization of sub-interpreters to the main one. But was there no errors
>> importing encodings in the sub-interpreters either, or did it not even try
>> to import the encodings package at all?
>>
>> For the record, I have all the encodings and stuff in all my Python
>> sub-interpreters and none of my pages are using global application group, so
>> it is not a generic problem that happens for everyone; just like with
>> EventScripts (the other project embedding Python I mentioned earlier) it
>> works fine for most people but fails to include the codecs for some people.
>>
>> It's too bad the error doesn't happen to me. If it did, I would surely dig
>> as deep as would be needed (even to edit Python's source code to add
>> additional debug messages) to find out what exactly causes it. I don't know
>> the internal structure of Python enough to be able to provide such edits for
>> remote debugging, though. But this is certainly an interesting problem and
>> not just mod_wsgi specific. If we can find out the cause and solution for
>> it, that would help not only your case but also plenty of people using other
>> embedded Python interpreters. (You might see that my motivation for actively
>> trying to participate in this particular problem is mostly because of the
>> similar problem in ES and there is a major pain that has been reported to
>> happen to more than just one user)
>>
>> --
>> 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.
>>
--
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.
