On Sat, Mar 17, 2012 at 1:44 PM, Niall Douglas <s_sourceforge@nedprod.com>wrote:
If by "Python side" you mean Boost.Python, then I agree: BPL has no support for GIL management at all, and it really ought to. This was one of the things that was discussed in the BPL v3 discussions on this list a few months ago.
Hey do you know any terms or thread names where I could go digging through some of those discussions? I'm just trying stuff superficially and finding some things that are at least interesting, but I'm not sure I got that stuff yet.
You need to clarify what you mean by "own subsystem". Do you mean "own process"?
In the model I'm using, a subsystem would be a thread taking care of a particular resource. In this case, I figured I would make the Python interpreter that resource, and install better guards around interacting with it. For one thing, rather than anything else grabbing the GIL, they would enqueue stuff for it to execute. That's about as far as I got with it in my head. I managed to unjam the deadlock I was experiencing by eliminating the contention the two conflicting threads were having with each other.
You're going to have to be a lot clearer here. Do you mean you want BPL to give up the GIL until the wait is done, or Python?
Something, somewhere. I wasn't being to picky. I wondered if there was a way to do it that I hadn't found with the regular Python headers.
Regarding inconsistency over releases and locks, that's 101 threading theory. Any basic threading programming textbook will tell you how to handle such issues.
I'm hoping I'm asking about, say, 102 threading stuff instead. ;) Specifically, I'm trying my darndest to keep explict lock controls outside of the main code because it really is hard to get right all the time. Rather, I am trying to apply some kind of structure. The subsystem model I did a terrible job of mentioning is an example, as well as using promises and futures. If there are tricks, features, or something similar to keep in mind, that would steer how I approach this.