I was not originally going to say anything but from what i have skimmed from all these emails seems like someone really needs multithread safety in boost python. Turns out I needed the same thing about 2 months ago, and I looked at TnFOX, changed a few things, patched a couple files, and I am fairly confident that what I have is at least a good short term solution until multithread safety is put into the real boost python. I was not going to post this because I did not want to spend the time making the project pretty for other people to use, but if whoever you are is so desperate as to spend a week talking about this then I guess I can at least post what I have. http://rapidshare.com/files/376177125/boost_python.rar I just ripped the two folders right out of my own project, whoever wants thread safety can pick out the files and put them how they want in their own project :p
A couple of things I noted while doing this that I think have come up here and a bit about what this patch does. This code will lock the GIL at every entry into python, and it will unlock it at every entry into cpp land. Python exceptions and cpp exceptions work, which was kind of tricky to get right. It should be noted that my code here is just me pounding a round peg into a square hole and should not be trusted 100%. I have some unit tests but its not nearly as thourally tested as I would like. About TnFox, I noticed it was doing a lot of complicated stuff like creating an interpreter per thread, saving gil states and doing a bunch of weird stuff. I only wanted a library where I could safety call into python from a different thread so all this does is manage the GIL lock appropriately. It will NOT allow 2 threads to run python code at the same time. If thats what TnFox does then that's impressive, but that's nowhere near what I needed so I just grabbed the ideas from invoke.hpp and added some locking structures of my own to complete this. Also if you do use this and you are trying to call into python from override objects like I was, I am sure you have been trying to lock the GIL with PyGILState_Ensure. I made it so that locking is not necessary. All GIL management should be handled by boost python in that code, there should be no read to lock the GIL in your own project anywhere. Thats about all I have to say, if I completely misinterpreted this thread please disregard. oh, it compiles fine in visual studio 2008/2010 and gcc, those are the compilers I currently use. Charles
_______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig
