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.
