Antoine Pitrou added the comment: > Umm, no. The whole point of the GILState API is that you can call it > from a thread which knows *nothing* about Python.
No to what? Any sane callback API allows to pass it some user data, that user data can just as well include the pointer to the desired interpreter. Really, that's the right way to do it. Since a new API is required, we can indeed add tweaks to the current API until the migration is done, but I'm quite sure any proper solution to the problem requires explicitly passing the interpreter. > There are going to be limitations on how effective this will be - it > still won't support *all* extension modules that use the PyGILState > APIs. It will, however, support many more of them than the status quo I still don't understand how that allows to "support some extension modules" (which ones?). A typical mod_wsgi setup uses several threads per daemon process, and each thread (AFAIU) uses a separate subinterpreter for its WSGI application instance (Graham, is that false?). Therefore, an externally-launched thread can relate to *any* of these subintepreters, which are themselves scheduled by the OS. > And you absolutely can control when the OS switches threads - > controlling that is what synchronisation primitives are *for*. I don't think mod_wsgi has access to enough hooks or information to do that satisfyingly (like the OS would do). Besides, I don't understand how mod_wsgi could have control over the scheduling of externally-launched threads. Therefore, an externally-launched thread could be scheduled at any time, and not only after the "right" interpreter thread was interrupted. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15751> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
