#Python entry icursor not working free#
To the right subinterpreter? The OS is free to schedule threads as it > threads in a process to a subinterpreter other than the main one.īut how does it know that the right externally created thread will point > subinterpreters, it just needs to be able to direct externally created > externally created threads to be able to call back into arbitrary > As I understand the situation, mod_wsgi doesn't need arbitrary If those private APIs *aren't* enough, then I'm missing something and this isn't going to be as easy as I thought. If a new PyGILState_SwitchInterpreter API is going to be able to solve this in 3.4, then I believe those private APIs should be enough to make it possible in *current* versions. (where si and st are the interpreter state and thread state for the target subinterpreter) Graham, even better would be if you could try the following combination: If I'm right, then calling _PyGILState_Init should convert the current crashes and deadlocks into a relatively less harmful memory leak (since the old entry in the TLS won't get deleted properly). I think the new method could just be a cleaner combination of _PyGILState_ReInit and _PyGILState_Init. Graham, looking at the current impl - have you experimented with just calling _PyGILState_Init() with the interpreter state and current thread state for the desired subinterpreter to see what happens? It would twiddle the autoInterpreterState and autoTLSkey entries in the pystate.c global variables to point to a different subinterpreter.Īs I understand the situation, mod_wsgi doesn't need arbitrary externally created threads to be able to call back into arbitrary subinterpreters, it just needs to be able to direct externally created threads in a process to a subinterpreter other than the main one. > GIL state APIs to implicitly create new thread states.
> a function that mod_wsgi can call to set the interpreter used by the Some details about this issue can be found in: The mechanism for forcing use of main interpreter is the directive: By default though, sub interpreters are used as noted. One can still tell WSGI applications under mod_wsgi to run in the main interpreter and in that case modules using PyGILState* do work. This is still only a seed of an idea (and it's entirely possible we've missed something), but it's a place to start in resolving this longstanding incompatibility. Graham Dumpleton and I spent some time discussing this at P圜on AU 2012, and we believe that the incompatibility can be resolved with a single API in the core: a function that mod_wsgi can call to set the interpreter used by the GIL state APIs to implicitly create new thread states. Messages (49)Ĭurrently, modules that use the PyGILState* APIs cannot be used with mod_wsgi, as mod_wsgi uses the subinterpreter support. Make the PyGILState API compatible with subinterpretersĪsvetlov, eric.snow, erlendaasland, felk, gabrielhae, grahamd, h-vetinari, jcea, maciej.szulik, mhammond, ncoghlan, phsilva, pitrou, python-dev, ronaldoussoren, seberg, vstinnerĬreated on 05:18 by ncoghlan, last changed 14:57 by admin.
0 kommentar(er)
