|
Graham Dumpleton
graham.dumpleton at gmail.com
Tue Apr 10 23:06:37 EDT 2007
On 11/04/07, David Schachter <ds at bittorrent.com> wrote: > Graham-- > > Thanks for the tip. I re-swigged the Python code and BDB XML no longer > locks up at first blush. (Out of context, the previous sentence makes > little sense.) I haven't done any testing beyond that yet. Thank you for > getting jiggy with my swiggy. > > George-- > > Is this something for the next 2.3.x release? > > -- David Schachter FWIW, am not sure why the -threads option is used as I can't see that it would be required when the package is used exclusively from Python code. The only time one would potentially need the GIL wrappers that SWIG puts in there is when some C code which doesn't currently have the Python GIL held or an active thread state makes a call to one of the generated SWIG wrapper functions. Unless the dbxml package has been specially designed to be used in embedded systems where C code is calling out of C code into dbxml/Python code and the calling C code hasn't performed any prior Python initialisation steps, this is unlikely to occur. Only other possibility is that dbxml specifically has sections where it releases the GIL but then wants to be able to perform a callback into Python code, but I can't see any instances of Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS being used in the code. The reason the GIL wrappers cause a problem for mod_python is that mod_python has already correctly acquired the GIL and created an active thread state, but such thread states are not registered with Python's simplified GIL API system because one is not meant to use the Python simplified GIL API system when multiple Python sub interpreters are used for various reasons. It says as much in the Python code and also I think the documentation. Not sure how much joy you will get with getting dbxml changed. Really need to find out exactly why dbxml authors think the -threads option is required. Graham > Graham Dumpleton wrote: > > Looking a bit further, the GIL macros are in my own stuff, but I > > suspect it doesn't get enabled because I don't use the -threads option > > to SWIG. I don't understand the consequences of the option, but > > changing: > > > > dbxml/dist/s_swig > > > > so that '-threads' isn't in swig_args for Python would probably get > > rid of the stuff. > > > > Would need to work out why they use the option in the first place as > > turning it off could break things if dbxml is dependent on it in some > > way. > > > > Graham > > > > On 11/04/07, Graham Dumpleton <graham.dumpleton at gmail.com> wrote: > >> Try rebuilding dbxml but ensure that compiler option: > >> > >> -DSWIG_PYTHON_NO_USE_GIL > >> > >> is used. > >> > >> I don't know when SWIG changed, it certainly didn't generate these > >> PyGILState calls the last time I played with it, which wasn't that > >> long ago, but it isn't going to work under mod_python the way they now > >> do it as the default. > >> > >> I'll have to look into this further when I get a chance as this new > >> behaviour of SWIG is going to cause all my Apache API SWIG bindings to > >> break. :-( > >> > >> Graham > >> > >> On 11/04/07, David Schachter <ds at bittorrent.com> wrote: > >> > > >> > Folks-- > >> > > >> > I'm having a problem embedding Berkeley DB XML into Apache with > >> mod_python. > >> > The first attempt to create an XmlManager causes a lockup in > >> Python--the > >> > Global Interpreter Lock is deadlocked, I think. (Stack trace > >> below.) Any > >> > ideas of how to debug? Is there a BDB XML Python expert? I checked > >> Google > >> > without success. > >> > > >> > The code to demonstrate the problem is simple and shown below. > >> When the > >> > line "xmlManager = dbxml.XmlManager()" is commented out, the code > >> runs ok. > |